- From: Chris Lilley <chris@w3.org>
- Date: Tue, 4 Apr 2006 18:11:07 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-svg@w3.org
On Tuesday, April 4, 2006, 4:38:18 PM, Boris wrote: BZ> Chris Lilley wrote: >> Such markup is not conformant to the schema for SVGT 1.2, but I assume >> you knew that. BZ> Of course. But I'm interested in how a non-validating UA (such as BZ> Gecko) would handle this. Note that the requirement is far less than validation; and SVG implementation knows what attributes are allowed on the elements it implements, and what the values are and what they do -because it has code for them. For other values, see "unsupported values". For attributes in other namespaces, they have no effect on rendering. >> This use of values for show and actuate which are not licensed by the >> SVG specification is outside the scope of the SVG specification. BZ> Sure. But it's within the scope of the XLink specification and the BZ> XLink specification completely defines the behavior. This is why I asked on the XLik list. And xLink defines some aspects of the behaviour, not all. As an example, if I have <svg:metadata/> and I then put xl:href="foo.jpg" on it, its clear that XLink says this is now a simple link. If I also put xl:show="embed" on it then its clear that XLink says the image should somehow form part of the presentation. How big is the image drawn, and where? Is this meta a timed element? Can its attributes be animated? What sort of DOM does it expose? XLink has nothing to do with that; its up to the application of XML (in this case, SVG). Well, if you were doing this in accordance with the svg spec you would use the image element; you would then have x,y,width and height to tell you where and how to display it and how it fits in the local coordinate system. You could look at the definition of the DOM on that element to see what it does. >> Don't do that. BZ> As an author, I don't. As a UA implementor, I have to assume that authors will BZ> ignore little things like schema; when that happens I need to know what my UA BZ> should do. Yes, agreed. BZ> Is the document in error in this case? If not, I have to render it. BZ> Then the question is "how". Robin has already quoted the text about unsupported values. So,its already covered. >> So your question is really, whether any random combination of XLink >> attributes can be used to override the semantics of any other element. BZ> Yes, and it seems to me that >> I asked this on the XLink public list: >> http://lists.w3.org/Archives/Public/www-xml-linking-comments/2006JanMar/0113.html >> (using your example, in fact) >> >> and got this response >> http://lists.w3.org/Archives/Public/www-xml-linking-comments/2006AprJun/0000.html BZ> Which just says, "Yes, the markup is not conformant to the SVG schema." Again, BZ> what does that mean in practice? Is the document in error? What does my UA do BZ> to handle this case? Its not in error, but it has unsupported values. The spec tells you what to doin that case. BZ> Also, note that the actuate="onload" case doesn't even depend on the BZ> document being rendered; it's somewhat analogous to, say, having an BZ> <html:script> element in the DOM. Good point, but its still an unsupported value. BZ> While SVG constrains the rendering BZ> behavior there (the <script> does not render), it does not constrain BZ> the semantics (the <script> executes). Even if the SVG document is BZ> in error, as far as I can tell based on the current spec. BZ> So as far as I can tell, as a UA implementor, the actuate="onload" BZ> case should actuate onload as required by the XLink specification. I BZ> see no provisions for doing otherwise, unless I happen to be a UA BZ> that completely abandons parsing the document and drops the entire BZ> DOM as soon as I detect non-conformance to the schema being used. I don't see how 'abandoning parsing' and 'dropping the DOM' enter into it. The document would still be parsed and would still have a DOM. >> so, basically, SVG describes what happens when allowed values for a >> particular element are used, consistent with the semantics of that >> element. BZ> Agreed. >> By using non-allowed values, you are making a new language BZ> As I read the XLink specification, authors are allowed to use any BZ> xlink-namespaced attributes on any elements in any language. Perhaps the XLink spec could usefully clarify whether it is aimed at developers of other specifications, which is my understanding, or aimed at being directly used in arbitrary combinations by content authors. BZ> Again, that may BZ> make the result non-conformant wrt the language's schema. But what does that BZ> mean in practice for a UA implementor? >> Redefining the semantics >> of existing elements seems like poor design, so you would be better >> using elements in a different namespace. BZ> Sure. I'm not speaking as an author here. I'm speaking as a UA BZ> implementor who wants to know how to handle the case of authors BZ> using said "poor design". Understood. I do see where you are coming from, here. BZ> Again, I see no problem in the SVG specification as it stands; I BZ> just wanted to be sure there is no problem with Gecko implementing BZ> XLink in addition to SVG No, that seems fine. But your next sentence does not follow: BZ> (that is, that they do not place BZ> contradictory constraints on what Gecko should be doing). Sounds BZ> like they don't -- once we don't match the schema, the SVG spec BZ> places no constraints, so we should follow the XLink spec. Well actually, for elements in the SVG namespace there are constraints, as mentioned; in fact, as Henry explicitly noted. So, for values which are unsupported *on that element in that namespace* you follow what the relevant spec says (ie SVG in this case). BZ> -Boris -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG
Received on Tuesday, 4 April 2006 16:11:13 UTC