Re: [SVGMobile12] Question on SVG implementation in an XLink-aware processor

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.

Sure.  But the impementation in question (Gecko) also has code for handling 
xlink:href on arbitrary DOM Element nodes, since the XLink specification defines 
the behavior for those cases.  It's not obvious to me why in cases when SVG 
doesn't define the xlink attribute behavior the definitions in the XLink 
specification would not apply.

> For other values, see "unsupported values". For
> attributes in other namespaces, they have no effect on rendering.

Sure.  But they do affect the DOM, and a lot of the XLink stuff is defined in 
DOM terms, not rendering.  That is, for example, an xlink:actuate="onload" link 
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?

Sure.  And for purposes of the presentation, I'd go with SVG (and probably not 
draw the image).  But for purposes of semantics, the correct thing to do would 
probably be to load the image.

> Well, if you were doing this in accordance with the svg spec you
> would use the image element

Right.

> Robin has already quoted the text about unsupported values. So,its
> already covered.

OK.  Good.

> Its not in error, but it has unsupported values. The spec tells you what
> to doin that case.

Where?

> 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.

Unsupported by SVG, not by XLink.  And XLink clearly specifies what should 
happen in this case.

> 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.

And per XLink as soon as the DOM node with actuate="onload" is parsed it 
triggers a load.

> 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.

That would have been nice, yeah.  But the boat sailed when XLink 1.0 went to 
REC, as far as I can tell.  At this point it's being used for both purposes, and 
XLink 1.0 (which is what SVG references as far as I can tell), as well as XLink 
1.1, allows both uses.

That is, a UA can implement SVG without implementing XLink (and just using the 
namespaced attributes in the way that SVG specifies).  A UA can implement XLink 
without implementing SVG.  If a UA implements 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.

But all those constraints mean is that the document is not conformant to the SVG 
schema.  I see nothing in SVG that then defines the behavior, while I do see 
explicit text in XLink that defines it.  If there's text in SVG that defines it 
and that I'm just missing, then the two specifications are in conflict, which 
makes my job as an implementor that much harder...

> So, for values which are unsupported *on that element in that namespace*

It's not clear to me that XLink allows unsupporting XLink-namespaced attributes. 
  It allows restricting the schema further (such that not all XLink-valid things 
are SVG-valid things).  But I see nothing in the XLink specification that allows 
SVG to override the meaning of well-defined XLink behaviors...

> you follow what the relevant spec says (ie SVG in this case).

It's not clear to me why SVG is more relevant than XLink for determining what to 
do with XLink-namespaced attributes that SVG does not concern itself with.

Perhaps we should start a parallel discussion on the XLink list?  I may, of 
course, be misunderstanding the response you got there, but if it says what you 
feel it says then it seems to contradict explicit statements that the XLink 
specification makes.

-Boris

Received on Tuesday, 4 April 2006 17:43:47 UTC