W3C home > Mailing lists > Public > www-svg@w3.org > April 2006

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

From: Chris Lilley <chris@w3.org>
Date: Tue, 4 Apr 2006 21:08:00 +0200
Message-ID: <607328338.20060404210800@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:34 GMT