I want to clarify some comments that I made before on this. I've seen a few
use cases that can make arguments for typed data in XSL, but they all seem
to me to be extraordinarily forced. Typing introduces its own complexities
into most computer languages, which is why a language like Javascript is
easier to create even if it is less rigorous and efficient than C++ or Java.
The reason that I bring up the second part (and I think it is important) is
that the function mechanism within XSLT lends itself to an object oriented
expression. If you create a namespace foo: and associate with that a series
of functions, those functions will typically have topical relationships to
one another ... a sql: namespace would wrap SQL access functionality, an
acc: namespace would wrap accounting functionality, and so on. Let's say I
have an XQuery namespace (xq:) which provides the interface into an XQuery
engine:
<xsl:function name="xq:new">
<xsl:param name="url"/>
<xsl:param name="paramNames"
<xquery id="{generate-id()}" path="{url}" paramNames="{$paramName}"/>
</xsl:function>
<xsl:function name="xq:process">
<xsl:param name="xqNode"/>
<xsl:param name="paramValues"/>
<xsl:variable name="qString">
<xsl:for-each select="tokenize(string($xqNode/@paramNames),',')">
<xsl:value-of select="concat(.,'=',$paramValues[position()],if
(position()!=last()) then '&' else '')"
</xsl:for-each>
</xsl:variable>
<xsl:copy-of select="collection(concat($xqNode/@path,'?',$qString))"/>
</xsl:function>
This would then be invoked as
<xsl:variable name="query1"
select="xq:new('http://www.myQueries.com/getFilmsToDate.xquery' ,
'id,date,actor')"/>
<xsl:for-each select="xq:process($query1,('foo',current-date(),'Michael
Caine'))">
<film title="{./@filmTitle}" date="{./@releaseDate}"
</xsl:for-each>
<xsl:for-each select="xq:process($query1,('foo',current-date(),'Catherine
Zeta-Jones'))">
<film title="{./@filmTitle}" date="{./@releaseDate}"
</xsl:for-each>
In this case, the "xquery object" defines in the xq:new function has a very
definite structure, one that can in fact be determined by a schema. This
structure (it's type) is important because what is passed here isn't just a
scalar value, but an entire XML structure. For that reason, it should be
reasonable to expect XSLT2 to support this kind of functionality:
<xsl:function name="xq:new" as="xqs:xquery">
<xsl:param name="url" as "xs:string"/>
<xsl:param name="paramNames" as "string"/>
<xquery id="{generate-id()}" path="{url}" paramNames="{$paramName}"/>
</xsl:function>
<xsl:function name="xq:process">
<xsl:param name="xqNode" as="xqs:xquery"/>
....
</xsl:function>
where the xqs: namespace points to an associated schema.
This is perhaps not the best example I can think of, but it does illustrate
the point -- if you're going to have type in XSL, then you should commit to
it completely. Functions should be capable of being overloaded (one of the
benefits of type, as it creates a particular signature). It should be
possible to test that a parameter or variable is in fact of a given type,
even if that type is complex. I still think that types in XSLT are a bad
idea, but if they have to be there to please the vendors, then let's at
least let the developers who are actually going to work with this muck have
some power for their pain.
-- Kurt Cagle
Inadvertently, I am sure, you omitted what
Kurt went on to say. I quote it
here for your convenience:
>I still contend that type doesn't belong
in XSLT, but if it is in there, it
>should make processes more efficient,
not less. If type needs to be there,
>then all of XSD should be supported,
such that an XSLT function can return
>an object of complex type Foo.
Would you be happy if the XSLT WG went on
to heed Kurt's second option and
implemented all of XSD Schema?
I don't know if he'd be happy, I'm sure I
wouldn't be happy since I don't want xsdl
forced on me, but on the other hand this
would be partially doing what I've argued in
some other thread long since for the
possibility of returning fragments from the
schema validation. Since to me an "xml type"
would be mostly sensible as a portion of a
tree. Of course my arguments was that
validation mechanisms should be more
abstract, to allow RNG as well, and to just
have rules about how a particular processor
implemented its particular validation
mechanism. The idea being of course that I
expected a lot of the smaller processors
would not support xsd at all, and opt
instead for schematron or RNG. But no-one
does anything to make me happy anymore
**sniffle**
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list