This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Draft 0.1 - call for comments
- To: xsl-list at lists dot mulberrytech dot com, Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments
- From: Francis Norton <francis at redrice dot com>
- Date: Thu, 01 Mar 2001 10:55:03 +0000
- References: <200103010810.BAA00662@localhost.localdomain>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Uche Ogbuji wrote:
>
> > > 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'.]
>
> I find this much more compelling than a built-in system of typeconstraints.
>
Well, you might guess from the fact that I host a W3C XML Schema FAQ [1]
that I don't exactly have anything against type constraint systems in
general. But I would agree that this is a project of pretty scary scale
and complexity, and ideally I would like to see an incremental
introduction into XSLT / XPath. For example really I like the idea of
doing Part 1 Datatypes first - given that it is relatively
uncontroversial and will fulfill a real need, for dates etc - while we
get to know Part 2 Structures a bit better.
Francis.
[1] http://www.schemaValid.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list