Re: [SVGMobile12] Interaction with XLink

On Thu, 8 Jun 2006, Erik Dahlström wrote:
> > >
> > > Where the attributes are explicitly set (by which I mean are present 
> > > in the source of the SVG content in question), they should be 
> > > interpreted as per the Xlink specification (see also your other 
> > > question, below).
> >
> > This seems to contradict the SVG specification, which implies that, 
> > e.g.,the following:
> >
> >   <svg xmlns=""
> > xmlns:xlink="">
> >      <a xlink:href="test" xlink:show="embed" xlink:type="simple">
> >        <rect width="100%" height="100%"/>
> >      </a>
> >    </svg>
> >
> > ...should render a black rectangle that is a link, whereas per XLink 
> > that link should render the file "test" in place of the black 
> > rectangle. Please clarify the SVG specification to state exactly how 
> > XLink attributeswith unexpected values are to be handled in an SVG 
> > context.
> The WG considers the spec to be clear enough, for unsupported values the 
> spec tells you how to handle them in the given context. Your example 
> uses xlink:show="embed" which the SVGT12 spec tells you is not supported 
> on the <svg:a> element so it should be treated as an unsupported value.

...which contradicts XLink, as mentioned above.

> > In particular, per XLink, this should not create a link:
> >   <svg xmlns=""
> >        xmlns:xlink="">
> >      <a xlink:href="test">
> >        <rect width="100%" height="100%"/>
> >      </a>
> >    </svg>
> >
> > Please clarify the SVG specification to state exactly how XLink semanticsare
> > being changed.
> >
> > Please clearly define, for all SVG elements, how XLink attributes must 
> > be treated when they do not have their expected values.
> Again, the WG considers the spec to be clear enough, the SVG Relax NG 
> schema does define the default values of xlink-attributes. The SVGT12 
> spec also says what attribute values are supported in the given context.
> Please let us know shortly if this does not address your concern.

It doesn't. SVG completely violates XLink, despite the SVGWG's claims to 
the contrary. This is a long-standing problem, which forces XLink 
implementations that also support XLink to either violate XLink, violate 
SVG, or violate XLink only for SVG, the latter case requiring that the 
XLink implementation have built-in knowledge of SVG.

Furthermore, it makes it impossible for non-SVG implementations to process 
SVG files according to XLink semantics and get reliable (correct) results, 
thus removing the entire point of reusing a generic language like XLink.

Since I do not expect the SVG working group to change its mind, please 
mark my disapproval clearly in your disposition of comments.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 8 June 2006 23:22:04 UTC