Re: [xsl] Re: Coordination of script in XHTML, SVG, and XSLT 1.1 (aka RDDL as a delivery vehicle...)

["Curt Arnold" <carnold@xxxxxxxxxxxxxx>]

Well there was a reason I started this thread on xml-dev since it touched on
multiple XML technologies, but the flow went to XSL-List and the official
comments lists have to be cc'd to get it into their issues process.  If this
thread is going to have much more life, we should either move to xml-dev or
start a separate list.

Starting an RFC is probably the best approach, text/ecmascript,
text/javascript, etc are already referenced in HTML and SVG so vnd or x
types don't address the deployed content types.  The RFC should cover
communication of behavior through scripting source, but through bytecode
archives and classes (application/java-archive, etc) , and traditional
programming languages (text/cpp).

Bjoern Hoehrmann <derhoermi@xxxxxxx> wrote (in response)
>>5. Behavior may be identified with a namespace URI

>of defining namespace URIs won't be successful. Further, this isn't
>sufficient. The Web requires MIME types for HTTP transactions; with
>respect to intelligent content negotiation the named entities still have
>to follow RFC 2048 (http://www.ietf.org/rfc/rfc2048.txt) and register
>MIME types for the named scripting languages.

I guess this wasn't clear without the context.  What I am saying here is
that a specific group of behaviors, independent of any particular
implementation, such as Example, Inc's date formatting routines for XSLT or
it's shape resizing routines for SVG may be identified by a URI such as
"http://www.example.com/XSLT-behavior/date-format"; or
"http://www.example.com/SVG-behavior/shape-resize"; and the processor can
pick the implementation that is most appropriate for it.

This is in essence what <xsl:script implements-prefix="nsprefix"/> was
doing, basically allowing you to identify multiple implementations of one
group of behaviors.  The processor could pick the implementation that is
appropriate to its platform either by using the contents of the script
element or using RDDL or another mechanism to locate yet another
implementation.

Here is an example from a previous message
(http://lists.w3.org/Archives/Public/www-svg/2001Mar/0011.html) that might
make the intent of using URI's to identify behavior clearer.

<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.c
lass"/>
   <!--  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>


I'm not quite sure how to interpret Kurt Cagle's comments
(http://lists.w3.org/Archives/Public/www-svg/2001Mar/0014.html).

There will comes a point when it is better to bind to a general purpose
programming language to an XML application instead of extending the
declarative capabilities of the XML application.  I don't see using script
to implement event handling in SVG to be a last resort, but a good partition
of responsibilities.  (Using script for scientific notation in XSLT would be
a hack)

The essence of <script> is to express the binding of behavior, expressed as
script, bytecode or whatever, and the DOM together.  The current mechanism
works well when you are pleased with running one scripting language on all
platforms.  This wasn't acceptible for XSLT 1.1 which needed the capability
to have multiple implementations so that the most efficient implementation
for the current platform could be used.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list