This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Draft 0.1 - call for comments
Jeni Tennison wrote:
>
> Hi Francis,
>
>
> > I can live with or without both of these, though since I do a fair
> > bit of schema processing across documents, I can see advantages to
> > exsl:reference being executable in for-each elements rather than
> > just using Xpath patterns.
> >
> > But multi-returns would fix it too.
>
> Can you give an example of the kind of schema processing where you
> think this functionality would be useful? It sounds as if it would be
> a good use case to focus discussion of these issues on.
>
I'm slightly embarrassed - I seem to have worked round all these
problems when I re-engineered my includes to use a common template - I
even posted it to xsl-list in answer to a query...
>From http://www.biglist.com/lists/xsl-list/archives/200101/msg00535.html
-----------------------------------------------------------------------
The context is working with XML Schemas which can include other schemas
via an xsd:include element. The code is quite satisfactory in the sense
that by using nodesets it recurses through the include tree in a
parallel wave-front, rather than having to zip-zag sequentially round
every twist in the twig line :)
<xsl:template name="gatherSchema">
<xsl:param name="schemas"/>
<xsl:param name="includes"/>
<xsl:choose>
<xsl:when test="count($schemas) < count($schemas | $includes)">
<!-- when $includes includes something new, recurse ... -->
<xsl:call-template name="gatherSchema">
<!-- ... with current $includes added to the $schemas parameter
... -->
<xsl:with-param name="schemas" select="$schemas | $includes"/>
<!-- ... and any *new* includes in the $include parameter -->
<xsl:with-param name="includes"
select="document($includes/xsd:schema/xsd:include/@schemaLocation)"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<!-- do something with the "$schemas" nodeset containing the root
nodes of all included schemas -->
</xsl:otherwise>
</xsl:choose>
</xsl:template>
-----------------------------------------------------------------------
I *did* have lots of problems when I started coding this, honestly!
I'll check some of my other transforms and see if I can find a good
scenario...
> >> > [Issue: Type tests] well, if we're going to add any type
> >> > functionality, having it in this read-only area,for XPath 1.0 data
> >> > types only, would cause the least baggage. Is the string / node-set
> >> > decidability problem sufficiently hard to work round to justify
> >> > this?
> >>
> >> I was thinking about things like the 'other document' functions at the
> >> end of Appendix B. The document() function's first argument can be a
> >> string or a node set, but with the 'other document' functions it has
> >> to be a node set to get the desired behaviour, and there's no way to
> >> test whether the right type of argument has been passed or not, nor to
> >> fail with a nice error message if it isn't.
> >>
> >> So the work around is to restrict the types that are acceptable to the
> >> function, which is fair enough, just might be a little confusing in
> >> these kinds of functions.
> >
> > Looks like it's adding up to a pretty compelling case for a read-only
> > "xpathType()" function.
>
> Something like:
>
> Function: string exsl:object-type(object)
>
> The exsl:node-type function returns a string giving the type of the
> object passed as the argument. The possible object types are:
> 'string', 'number', 'boolean', 'node-set' or 'RTF'.
>
> [Note: The description would change in version 1.1 (matching XSLT 1.1)
> to:
>
> The exsl:node-type function returns a string giving the type of the
> object passed as the argument. The possible object types are:
> 'string', 'number', 'boolean', 'node-set' or 'external'.]
>
Sold.
Francis.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list