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) &lt; 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