- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Sat, 28 Sep 2002 16:47:35 +0100
- To: www-tag@w3.org, "Didier PH Martin" <martind@netfolder.com>
- Cc: "'Eric van der Vlist'" <vdv@dyomedea.com>
Hi Didier, > Thinking more about it. This would lead to a domino effect. If we > want to make the XML processing tools aware of this mapping feature, > then XSLT will have to be updated to include CSS as a processing > element. Otherwise, XSLT has no clues to know that an element is > mapped to an xlink characteristic. > > So the impact is: > XSLT will need to import and process the CSS in order to map the > element and to be able to match the templates with the mapped > characteristic. Said differently if the <a> href attribute is mapped > to the xlink:href attribute, the to make the XSLT engine to be able > to process a template such as <template match="@xlink:href">, then > it need to include and process the CSS document providing the > mapping. I can see what you're saying -- that if CSS were the only place in which links were specified then for XSLT and other XML processing technologies to recognise a link as a link, they would have to understand CSS syntax. I think that I agree with you that CSS isn't the answer to all the problems here, but it does meet some of the requirements, as I see them, so perhaps we can learn something from it. The requirements (which I'm just deriving from what I've gathered from this discussion) that providing a CSS mapping handles are: 1. The linking solution should not impose its own naming scheme 2. The linking solution should be able to handle multiple links from the same element, whether expressed as attributes or nested elements 3. The linking solution should be able to express different linking semantics/behaviour at different levels, for example: - elements with the same name (or of the same type, such that all <a> elements are treated the same way) - elements with particular attributes (such that all elements with an xlink:href attribute are treated the same way) - individual elements (e.g. local overriding of the equivalent of xlink:role) The requirement that it doesn't handle, as you've isolated above, is: 4. The linking solution should have minimal impact on the processing requirements made on XML applications As I see it, XLink satisfies #4 and partially satisfies #2 and #3 but really falls down on #1. HLink satisfies #1, partially satisfies #2 and #3, and falls down on #4 (though less heavily than CSS, since at least it's XML!). Let me think... something that can select elements with the same specificity as CSS, that uses an XML syntax and that's already used in many processing pipelines... sounds like a job for XSLT to me. (But then *everything* sounds like a job for XSLT to me ;) Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Saturday, 28 September 2002 11:54:56 UTC