Re: [xsl] [exsl] Draft 0.1 - call for comments

[Uche Ogbuji <uche dot ogbuji at fourthought dot com>]

> > "Issue: RTF error - should generating result nodes be an
> > unrecoverable error? "
> >
> > I like it as you have it now: error or ignore the nodes.
> 
> What do you think about David C.'s suggestion of having RTFs returned
> unless there's an exsl:result element in amongst the nodes that are
> generated, in which case the select attribute of the first exsl:result
> element is used as the return value?

I can't get my head around all the implications right away.  My only immediate 
reaction is that it seems rather contrived.

> > "Issue: Type tests - should this specification define functions to
> > test the type of values passed as parameters? Several XPath
> > functions allow an argument to be either a string or a node set, but
> > treating a string as a node set will cause an error and there's no
> > way to detect whether a variable value is actually a string or a
> > node set."
> >
> > Oh boy. Pet peeve of mine. I don't think there should be type tests.
> > I'm of the strong opinion that it is a mistake that so many
> > languages provide special status to data type among factors in
> > program correctness.
> 
> But then in a later email it sounded as if you agreed to:
> 
> >> Something like:
> >> 
> >>   Function: string exsl:object-type(object)
> >> 
> >>   The exsl:object-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:object-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'.]
> >
> > I find this much more compelling than a built-in system of
> > typeconstraints.
> 
> Have I interpreted you correctly?  You wouldn't object to an
> exsl:object-type function?

In my first post I think I must have understood.  I thought the idea was 
adding type constraints to parameter specifications, which I still oppose.  I 
don't have a problem with a run-time type identification function.

And of course, using this, people who really like strongly-typed systems can 
have their cake:

<exsl:function name='my:func'>
  <xsl:param name='x'/>
  <xsl:if test="not (exsl:object-type(x) = 'string')">
    <xsl:message terminate='yes'>You punk!</xsl:message>
  </xsl:if>
  ...
</exsl:function>


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



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