- From: Jim Ley <jim@jibbering.com>
- Date: Mon, 9 Sep 2002 18:59:44 -0000
- To: "Charles McCathieNevile" <charles@w3.org>
- Cc: "WAI Cross-group list" <wai-xtech@w3.org>
"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