- From: Chris Lilley <chris@w3.org>
- Date: Tue, 4 Apr 2006 21:08:00 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: www-svg@w3.org
On Tuesday, April 4, 2006, 7:43:32 PM, Boris wrote: BZ> Chris Lilley wrote: >> 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. BZ> Sure. But the impementation in question (Gecko) also has code for handling BZ> xlink:href on arbitrary DOM Element nodes, since the XLink specification defines BZ> the behavior for those cases. It's not obvious to me why in cases when SVG BZ> doesn't define the xlink attribute behavior the definitions in the XLink BZ> specification would not apply. >> For other values, see "unsupported values". For >> attributes in other namespaces, they have no effect on rendering. BZ> Sure. But they do affect the DOM, and a lot of the XLink stuff is defined in BZ> DOM terms, not rendering. I understand what you mean, although I suspect the XML Core WG would disagree with the characterization. BZ> That is, for example, an xlink:actuate="onload" link BZ> would activate even if it's not rendered (eg via CSS display:none). >> 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? BZ> Sure. And for purposes of the presentation, I'd go with SVG (and BZ> probably not draw the image). But for purposes of semantics, the BZ> correct thing to do would probably be to load the image. Problem is that there you overload the term semamtics. The semantics of svg, i.e. the aspect of reality that the svg markup models or captures, is geometry. >> Well, if you were doing this in accordance with the svg spec you >> would use the image element BZ> Right. >> Robin has already quoted the text about unsupported values. So,its >> already covered. BZ> OK. Good. >> Its not in error, but it has unsupported values. The spec tells you what >> to do in that case. BZ> Where? C.2 Unsupported elements, attributes, properties, attribute values and property values >> 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> Unsupported by SVG, not by XLink. And XLink clearly specifies what should BZ> happen in this case. No, you miss the point. Unsupported does not mean "globally unknown". Besides, SVG itself understands some of those values (but on other elements). The value is unsupported on the particular element. If you have an SVG implementation as well as an XLink implementation, the SVG implementation can tell the XLink one that this value is unsupported on this element. Its disallowed, if that makes it clearer. >> 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. BZ> And per XLink as soon as the DOM node with actuate="onload" is parsed it BZ> triggers a load. It gets the load event when the whole document is parsed, no? By that time the DOM has been built and the attributes that are unsupported/disallowed have been marked. >> 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> That would have been nice, yeah. But the boat sailed when XLink 1.0 BZ> went to REC, as far as I can tell. At this point it's being used for BZ> both purposes, and XLink 1.0 (which is what SVG references as far as BZ> I can tell), as well as XLink 1.1, allows both uses. Fair point. SVGT 1.2 is updating to use XLink 1.1, of course, since part of the rationale for 1.1 was to make elements with an xl:href and no xl:type be simple links. Now they have done this, we can update to point to them. BZ> That is, a UA can implement SVG without implementing XLink (and just BZ> using the namespaced attributes in the way that SVG specifies). A UA BZ> can implement XLink without implementing SVG. If a UA implements BZ> both, then the issues I have arise. >> 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. BZ> But all those constraints mean is that the document is not conformant to the SVG BZ> schema. This is not about validation. BZ> I see nothing in SVG that then defines the behavior, while I do see BZ> explicit text in XLink that defines it. If there's text in SVG that BZ> defines it and that I'm just missing, then the two specifications BZ> are in conflict, which makes my job as an implementor that much BZ> harder... >> So, for values which are unsupported *on that element in that namespace* BZ> It's not clear to me that XLink allows unsupporting XLink-namespaced BZ> attributes. It allows restricting the schema further (such that not BZ> all XLink-valid things are SVG-valid things). But I see nothing in BZ> the XLink specification that allows SVG to override the meaning of BZ> well-defined XLink behaviors... >> you follow what the relevant spec says (ie SVG in this case). BZ> It's not clear to me why SVG is more relevant than XLink for BZ> determining what to do with XLink-namespaced attributes that SVG BZ> does not concern itself with. On an element in the svg namespace, its pretty clear which is the relevant specification; and there are no XLink-namespaced attributes under discussion that SVG is not concerning itself with. BZ> Perhaps we should start a parallel discussion on the XLink list? I was working up to suggesting that myself. BZ> I may, of course, be misunderstanding the response you got there, BZ> but if it says what you feel it says then it seems to contradict BZ> explicit statements that the XLink specification makes. 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 19:08:05 UTC