Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions? From: Alexey Gokhberg <alexei@xxxxxxxxxx> Date: Fri, 02 Mar 2001 18:15:58 +0100 |
Steve Muench wrote: > > Clark, > > |<xbind:module > | name="a-language-independent-uri-that-refers-to-functionality"> > | <xbind:function name="format"> > | <xbind:param name="date" type="string" /> > | <xbind:param name="format" type="string" /> > | <xbind:return type="string" /> > | <xbind:comment> > | This function formats a date in ISO 8601 > | according to the format string. > | </xbind:comment> > | <xbind:implementation > | language="java" > | package="java:com.example.datestuff.DateRoutines#format" > | /> > | <xbind:implementation language="javascript"> > | ... > | </xbind> > | </xbind:function> > |</xbind:module> > > The proposal above is identical to <xsl:script> except > for the fact that your more formally defining the functions > and returns. > I do not agree. It is not identical at all. There is a fundamental difference. First of all, <xsl:script> is an integral part of the XSLT stylesheet. In contrast, <xbind:module> is intentionally an external resource. It is never embedded into a stylesheet; it is always referenced by it. Two layers - the stylesheet logic and the available language bindings - are completely separated - in contrast to the XSLT 1.1 proposal where these layers are deliberately mixed. The XBIND resources are relatively independent on XSLT stylesheets - it is possible, for instance, implement some mechanisms for cascading XBIND definitions (as CSS stylesheets are cascaded) - some proposals already appeared on this list. > Imagine for a moment that <xsl:script> were named > <xsl:library> instead, but went otherwise unchanged. > > You then have: > <xsl:stylesheet xmlns:foo="a-language-independent-uri-that-refers-to-functionality"> > > <xsl:library implements-prefix="foo" language="XXX" src="uri"/> > <xsl:library implements-prefix="foo" language="YYY" src="uri"/> > > </xsl:stylesheet> > This probably demonstrates that with <xsl:script> one can *emulate* some functionality provided by XBIND. However, the well designed technology must *enforce* use of correct design principles, not just *allow* that. > Modulo the additional info about args and return types, > see your <xbind:module> plus multiple <xbind:implementation> > children as isomorphic to the sample number of <xsl:library> > elements. They both have "a-language-independent-uri-that- > refers-to-functionality". They both list multiple implementations > of that functionality. > You can throw <xbind:param>, <xbind:return>, etc. away - they are very important. They are not *additional* - they are *essential* features. The XBIND vocabulary provides the platform-independent description of interfaces (it is a kind of light-weight XML-based IDL). This information may be used by XSLT processor to provide early bindings, handle type checking and type coercion, provide platform-specific optimization, even to generate interface reference manuals. The stubs can be generated for platforms that do not allow dynamic function calls (for instance, C and C++). A lot of useful things can be done with XBIND - this is why it is moved to the separate layer. Unfortunately, XSLT 1.1 draft does not even try to address all these issues, concentrating on the brutal and straightforward binding between XSLT and Java/JavaScript. Regards, Alexey Gokhberg Unicorn Enterprises SA XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RDDL as a delivery vehicl, David Carlisle | Thread | [xsl] xbind:module == xsl:script + , Clark C. Evans |
[xsl] Debugging tool for XSLT, Raj Avula | Date | Re: [xsl] RDDL as a delivery vehicl, Steve Muench |
Month |