Re: [xsl] re: generation of qnames/prefixes in content and value [was xbind:module....]

[Curt Arnold <carnold at houston dot rr dot com>]

> 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%">
   <defs>
   <!--  java implementation used preferentially by Batik   -->
   <script implements="http://www.example.com/cad-like-behavior"
       type="application/java-archive"
src="jar:http://www.example.com/cad-like-behavior/cad.jar!/com/example/cad.class"/>
   <!--  COM implementation used preferentially by Adobe SVG
              (type didn't seem appropriate)  -->
   <script implements="http://www.example.com/cad-like-behavior"
       src="clsid:3545465756-5656-5757-5876769696"/>
   <!--   ecmascript behavior used if others aren't supported  -->
   <script implements="http://www.example.com/cad-like-behavior"
       type="text/ecmascript">
        alert("Advanced functionality is not supported on this platform");
        ...
    </script>
    </defs>
</svg>

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