Re: Question about forward and backward compatibility

On Tuesday, December 7, 2004, 6:15:16 PM, Robert wrote:


ROC> I'm trying to understand how authors write SVG content that will be
ROC> compatible across different SVG versions and user agents.

ROC> 1) Is there a way for authors to write a single SVG file that will
ROC> take advantage of SVG 1.2 features but degrade gracefully in a user
ROC> agent supporting only 1.1? It appears not, since the 1.1 user agent is
ROC> required to visually show error due to the presence of 1.2-specific
ROC> elements and attributes.

You should take a look at the switch element and the requiredFeatures
attribute to see how to do this.


ROC> 2) Given the presence of 'switch' and feature strings, are user agents
ROC> allowed to implement any SVG 1.1 subset that is exactly the union of a
ROC> set of feature modules? Or is this now officially deprecated by SVG
ROC> 1.2 WD section 2?
ROC> http://www.w3.org/TR/SVG/feature.html
ROC> http://www.w3.org/TR/SVG12/profiling.html

Implementing random subsets is not encouraged, no. Recognizing that a
given implementation might not go from 0% to 100% in its first release,
we recommend first implementing SVG Tiny 1.1, then gradually improving.
In addition, some classes of implementation (eg printers, server-side
transcoders) can usefully be static rather than dynamic (noanimation, no
interactivity).

ROC> 3) It has been useful in our work on CSS to prototype our
ROC> implementation of new CSS features by making the properties first
ROC> available with a -moz prefix, and then once our implementation is
ROC> solid enough (which depends partly on people experimenting with our
ROC> releases), we make the properties available with the standard names
ROC> too.

To be clear - in the implementations, not in the specs. I have not seen
any -css2 or =--css3 properties in the specs. I agree that things like
-moz-opacity were a good implementation strategy. Batik took a similar
approach when implementing SVG 1.2 features on an experimental basis (it
required using a Batik extension namespace and a special build where the
extensions were recognized).


ROC> It's not clear to do something similar with SVG. One option is to
ROC> initially enable our SVG prototype only via a Mozilla-specific
ROC> nonstandard MIME type, which lets Mozilla-specific application authors
ROC> and experimenters play with it, and later (mid 2005 for SVG Basic?)
ROC> enable it under the real MIME type and for mixed documents, once we're
ROC> satisfied that it meets correctness, performance and W3C profiling
ROC> requirements. We're looking for feedback on this.

I would see little value in that; once a specification is a
Recommendation, its no longer 'experimental'. So, requiring a specific
mozilla media type would only divide the market.



-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Thursday, 23 December 2004 11:13:27 UTC