Re: [xsl] re: generation of qnames/prefixes in content and value [was xbind:module....]
Subject: Re: [xsl] re: generation of qnames/prefixes in content and value [was xbind:module....]|
From: Curt Arnold <carnold@xxxxxxxxxxxxxx>
Date: Sat, 03 Mar 2001 22:25:30 -0600
See http://www.w3.org/TR/xslt20req #1.5 about QName-aware string functions
Also, isn't the prefix completely irrelevant as long as
the prefix that the XSLT processor generates resolves to
the same namespace URI that you are talking about?
That is, it should not matter if the XSLT processor
spits out "ns00123:integer" instead of "xsd:integer"
as long as the prefix "ns00123" is mapped in scope
to the same namespace URI that the convential "xsd"
prefix is mapped to, right?
You're right on both points, however they don't contradict the need to
use the uri instead of the prefix for applications that need to be
generated by XSLT 1.0 like SVG, since there is no mechanism to output a
prefix (even a arbitrary one) corresponding to a uri as an attribute value.
The more I think about it, the more I would like the ability to have
multiple implementations of the same behavior in SVG along the lines
proposed in the XSLT 1.1 draft. Multi-platform SVG behavior hasn't been
a serious issue yet since there is only one implementation that
currently supports scripting and the assumption is that to be portable
you would code everything in Ecmascript.
However, really complex behavior, such as detecting line intersections
when dragging a shape with connecting lines, could overtax the
capabilities of Ecmascript and could better be implemented in a compiled
language like Java, C# or C++. However, if you have to use choose one
and only one implemention in the SVG file, then the resulting file is
going to be sub-optimal on the other platforms.
If SVG had something along the lines if XSLT 1.1's implements, then
multiple implementations of the same behavior could be provided and the
one most appropriate for the platform could be chosen by the viewer.
<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%">
<!-- java implementation used preferentially by Batik -->
<!-- COM implementation used preferentially by Adobe SVG
(type didn't seem appropriate) -->
<!-- ecmascript behavior used if others aren't supported -->
alert("Advanced functionality is not supported on this platform");
p.s. I've used src="" instead of xlink:href="" intentionally. Since it
is a requirement of XML Schema to provide a mechanism that the existing
<xhtml:script src=""/> can be made consistent with XLink, it would seem
best if SVG would stay consistent with XHTML and rely on the facility
provided by XML Schema.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list