DR 09-0312 - WML: RelyOnVML

[Shawn Villaron]

Because today the only one in the standard is for VML.  If someone put together an amendment saying that we needed to add new support for persisting options for output formats, then we'd have a different discussion.

My only point is the fascination over "VML."  It has nothing to do with part 4 and has nothing to do with the content stored in the Open XML container.

So we'll remove it.

From: Francis Cave [mailto:francis at franciscave.com]
Sent: Sunday, March 21, 2010 8:45 AM
To: Shawn Villaron; 'Jesper Lund Stocholm'; 'SC 34 WG4'
Subject: RE: DR 09-0312 - WML: RelyOnVML

<HastyClarification>

I'm NOT advocating that we add a new attribute 'relyOnOuputFormat'. Making use of an existing feature (in Part 3?) that would achieve the same end would be my preference.

Francis

</HastyClarification>



From: Francis Cave [mailto:francis at franciscave.com]
Sent: 21 March 2010 15:41
To: 'Shawn Villaron'; 'Jesper Lund Stocholm'; 'SC 34 WG4'
Subject: RE: DR 09-0312 - WML: RelyOnVML

Exactly. If we accept the principle of enshrining formal names in attribute type names, you'd have to add 'relyOnXXX' for every conceivable output format XXX for which a similar feature needed to be added. Can you explain why a special attribute is needed for VML that is not needed for other formats (e.g. EPSF, SVG,...)?

If you had an attribute 'relyOnOutputFormat', taking a string value to indicate the format, or possibly even a controlled value, that would be more generic and flexible, surely.

But maybe I'm misunderstanding something here...

Francis



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

Can you help me understand what special status we're making for VML in part 1?

This element is like saying "relyOnCSS" ...

From: Francis Cave [mailto:francis at franciscave.com]
Sent: Sunday, March 21, 2010 6:39 AM
To: Shawn Villaron; 'Jesper Lund Stocholm'; 'SC 34 WG4'
Subject: RE: DR 09-0312 - WML: RelyOnVML

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/d5099dd7/attachment-0001.htm>