DR 09-0312 - WML: RelyOnVML

[Francis Cave]

It does seem odd to me to accord VML a special status in Part 1, by having
an attribute that specifically refers to it. On the other hand, it is
entirely reasonable that applications that support OOXML Strict should be
able to store information in a document that relates to specific formats
other than OOXML Strict in which a document can be saved. It would be more
logical to use a more generic way of storing such information. Isn't this
what MCE is for?

 

So, I would agree that the existing feature needs to be available in OOXML
Transitional for legacy reasons, but I feel that a more generic alternative
is needed for Strict. To my mind, finding a way of doing this that uses what
we already have in Parts 1 and 3 would be preferable to adding new features.

 

Francis

 

 

 

From: Shawn Villaron [mailto:shawnv at microsoft.com] 
Sent: 19 March 2010 14:15
To: Jesper Lund Stocholm; SC 34 WG4
Subject: RE: DR 09-0312 - WML: RelyOnVML

 

We can remove it, but I would like to clarify a few things.

 

1.       I don't think we can really tell implementers that they can't
create a publishing output using a technology not specified in 29500.  

2.       Other companies have built products on top of VML before ( e.g.
Google Maps ) so we shouldn't draw too many conclusions about VML's utility
( or lack thereof )

3.       The existence of the relyOnVML element doesn't create a dependency
on Part 4.  

 

So on the grounds that we should never string the letters V, M and L
together, in that order, can we remove the tag from the strict.  It does
need to remain in transitional for compatibility reasons.

 

From: Jesper Lund Stocholm [mailto:jesper.stocholm at ciber.dk] 
Sent: Thursday, March 18, 2010 11:58 PM
To: Shawn Villaron; SC 34 WG4
Subject: RE: DR 09-0312 - WML: RelyOnVML

 

Good morning all,

 

We are aware of the details you provide  below. Our concern is that first of
all, the attribute "sticks out" - even though it doesn't mean that VML can
be used within OOXML<S>. But we also feel that the attribute is redundant in
OOXML<S>. VML cannot be used within OOXML<S> so being able to specify that
the content should be "Saved to web" using VML - when VML cannot be used in
OOXML<S> seems wrong. Further VML is a technology that is (browser-wise)
only implemented in Microsoft Internet Explorer so RelyOnVml is a reference
to a technology that only exists in a Microsoft product. And finally the
existence of RelyOnVml in Part 1 makes a dependency to Part 4, since an
application encountering this attribute with a value of "true" in a strict
document will need to implement functionality from Part 4 to honor the
original user's intent.

 

So yes, we still wish to have the attribute removed.

 

:o)

 

Jesper Lund Stocholm
ciber Danmark A/S

 

From: Shawn Villaron [mailto:shawnv at microsoft.com] 
Sent: 18. marts 2010 23:10
To: 'SC 34 WG4'
Subject: DR 09-0312 - WML: RelyOnVML

 

This is in regards to the DK defect report. 

 

I believe that there may be a misunderstanding regarding the meaning of this
element as it doesn't relate to the BRM resolution regarding the limiting of
VML to the Transitional conformance class.

 

Many applications have the ability to generate published versions of their
documents that are optimized for viewing on the web.  Microsoft Word has
this ability, and in its web publish format, it has the ability to use VML
as a graphics format.  This ability is exposed to end users.  To keep track
of end user preferences, Microsoft Word would write out the end user
preference into the binary and XML versions of the document so that future
publishing would use the previous setting.  And since the migration to Open
XML was about preserving data found in those binary and XML files, this end
user preference was included in the standard and is represented by the
relyOnVML element.

 

To be 100% clear, this element has absolutely no impact on whether or not
VML is allowed to be used in the WordprocessingML document.  

 

In light of this, do we still believe it should be removed?

 

Thanks,

 

shawn

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20100321/e032e419/attachment.htm>