[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [exsl] Draft 0.1 - call for comments

Subject: Re: [exsl] Draft 0.1 - call for comments
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Mon, 26 Feb 2001 13:59:35 +0000
Re:  [exsl] Draft 0.1 - call for comments
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.