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%">
  <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


Current Thread