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

Subject: Re: [xsl] [exsl] Draft 0.1 - call for comments
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Mon, 26 Feb 2001 13:59:35 +0000
Hi Francis,

> OK, I think I understand now. If this is how exsl:reference-of is
> going to be used, would it be more intuitive to call it
> exsl:add-node? Or could it also be used in non-"add-node" ways?

Someone else suggested exsl:append, which again is roughly similar. I
think the exsl:reference-of name conjures the fact that the resulting
node set is constructed of references to nodes (though this also
implies a new 'reference' data type).

Both exsl:append and exsl:add-node sound more procedural - it's as if
you are *changing* the value of a variable (even though you aren't as
such), which we know is an absolute no-no.

> 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.

>> > [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'.]

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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


Current Thread