Re: XAG 2.3 and xlink

"Charles McCathieNevile" <charles@w3.org>
> One of the arguments for xlink in the first place is that there are
lots of
> people who want to be able to make links (the bit that makes the Web
> different to a collection of documents). If people cannot understand
every
> XML language and all its implications, then being able to understand
links in
> detail might be helpful - you don't really know the meaning of the
things in
> the page, but you know this one points to another page, and there are
some
> words around it that sort of make sense. Navigating blind is a step
forward
> from not being able to navigate at all - eventually you can build up a
map
> that helps to interpret things in it.

My problem with this interpretation, is that to be useful we need to have
more than the simple xlink:href, you need xlink:actuate, show etc.  Which
for SVG means you need to parse the DTD, which seems to ratchet up the
level of complexity our generic XML processors are.  In SVG without a dtd
specified (if we're using SVG in multi-namespace documents etc. a DTD
isn't likely to be posible, as the xhtml/mathml/svg dtd notes - that's
probably the limit.) you have many different usages of links, they're
used as hyperlinks, to include external images, to reference patterns, to
reference text, patterns, textPaths (but not clip-paths), altGlyph,
patterns,filters in fact too many for me to even remember here.

The majority of these links (in SVG) are pretty useless - without knowing
SVG you're not going to know what a reference to a clip-path element
means - so SVG's usage of xlink seems to create trouble for non SVG aware
agents who are searching for links. (I'm not trying to criticise SVG,
it's just the main user of XLINK that I know)  Yes these tools will know
that the image element is in some way linked to the textpath element, but
without the DTD it doesn't know how, and with it only really knows show
"other" but do it "onLoad"

For example, if a textPath in Document A refers to a textPath in Document
B are we really saying that it's useful for a non SVG aware to perform
something on that link?  Other than for genuinely linking where I agree
xlink:href is very useful.  These actuate onLoad etc. are the ones I'm
not sure about, certainly where the non href attributes are hidden in a
dtd.

(There's no schema for SVG currently, but the last one they published for
1.1 didn't seem to specify the fixed values, but I imagine that's just
one of the bugs in the schema, I don't believe there's any problem with
doing it.)

As I say and this is a seperate issue to the one I initially raised in
the thread, that of element based equivalents being a harder "sell", than
attribute based ones, which xlink also forces by the one link per element
restriction.

Jim.

Received on Monday, 9 September 2002 15:06:25 UTC