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

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