- From: Robert O'Callahan <rocallahan@gmail.com>
- Date: Tue, 18 Jan 2005 09:23:03 +1300
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: www-svg@w3.org
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