Re: Question about forward and backward compatibility

On Mon, 17 Jan 2005 21:00:22 +0100, Robin Berjon <robin.berjon@expway.fr> wrote:
> Robert O'Callahan wrote:
> > Chris Lilley wrote:
> >> You should take a look at the switch element and the requiredFeatures
> >> attribute to see how to do this.
> >>
> > I know about that. My question is, doesn't the letter of the 1.1 spec
> > require 1.1 user agents to show error when they encounter 1.2 tags and
> > attributes, even if they're under a switch?
> 
> No, it would be an error if the unknown elements/attributes were the
> rendered branch of the switch. The non-rendered branches can contain all
> sorts of stuff that the implementation doesn't understand. Otherwise the
> implementation would have to know what it doesn't implement, which is
> obviously impossible when you factor in new versions of the language.

Nooo... the implementation knows what it does implement, and anything
else is an error...

But okay. I accept your interpretation but I think it needs to be made
a lot clearer.

> Question: would you be helped by a scheme in which unrecognized SVG
> elements and attributes would cause only the subtree to be in error and
> entirely not rendered, leaving the rest of the document alone? The
> entire document would not be considered in error unless a mustUnderstand
> attribute is set to true for an ancestor of the subtree in error. This
> would simplify the evolution of SVG versions, as well as incremental
> implementations.

That sounds like a good way to go. You'll have to clarify which
subtree gets not rendered, especially when the error occurs in content
that is referenced elsewhere.

> > Unfortunately being SVG Tiny would force us to disable a bunch of
> > features but still do animation, which we won't be able to do before our
> > next release. But otherwise it sounds like a good idea to me.
> 
> In your case I don't think it's an option since IIRC you have everything
> except animation and fonts, both of which are Tiny features (for fonts
> it's only the basic subset but still). I agree with Chris that random
> subsets is not encouraged, but the union of complete feature-sets isn't
> completely random and better than a) totally random features and b)
> nothing. It's easy to tell users that a given implementation supports
> "everything except animation and fonts", it gets a lot harder to say
> that it "supports everything minus <insert long list of random deltas>".

Sure.

> > Why is using an extension namespace better than using an extension MIME
> > type?
> 
> The extension namespace means that within the document itself it is
> clear which parts are extensions. It also means that on the file system
> you can call your document .svg instead of .mozsvg. In fact, in XML
> using different namespaces is the equivalent of using vendor prefixes
> like -moz- in CSS. You wouldn't want to have to call your CSS with a
> single Mozilla extension in it .mozcss and have to send it using the
> text/x-mozilla-css media type.
> 
> That being said that's a strategy that works well to implement features
> of a spec that's in development (which is the case both for the -moz-
> CSS properties and Batik's SVG 1.2 extensions). I don't think it flies
> for implementations in development of a stable spec. You don't wait to
> have 100% of CSS implemented to turn it on, I suggest doing the same for
> SVG.

Okay. But actually I suspect subset implementations of SVG won't fare
as well as with CSS, they're different beasts.

Rob

Received on Monday, 17 January 2005 20:23:05 UTC