[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: re: generation of qnames/prefixes in content and v

Subject: Re: 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
c xml prefix generation
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.