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

Re: XSLT V 1.1

Subject: Re: XSLT V 1.1
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Sat, 09 Sep 2000 15:21:04 -0700
nodeset to string
----- Original Message ----- 
From: Didier PH Martin <martind@xxxxxxxxxxxxx>


Hi Didier,

> 4. document() should accept only URI.
> 
> Didier replies:
> ON the other hand,  to be able to include a node in the function document()
> is very useful. For instance to set as parameter the value of an attribute.
> As an example, imagine an Xlink interpreter implemented  with XSLT. Then, in
> that case we would have ....document(@xlink:href) if the current context is
> set to an xlink enabled element.

Sorry, I was not accurate. I should say something like  "URI in form of string 
or node ( or variable ), or whatever". The point is that semantics of document() 
should be: get the nodeset out of something defined  by URI 
( URI could be in any form ). In fact, because the 'hidden conversion'
of nodeset to string is 'get the PCDATA', I think that 

<xsl:variable name="url">
<part1>http:somehost</part1>
<part2>/some/path</part2>
</xsl:variable>

<xsl:copy-of select="document($url)"/>

should be equal to 

<xsl:copy-of select="document( 'http://somehost/some/path'  )"/>

At least it will be consistent with:

<xsl:value-of select="$url"/>

( Which displays:  http://somehost/some/path )

Needless to say that this is far away from current semantics of document(),
which is currently using the word "object"  to describe the type of argument
it receives! So does key() function. They both are weird. Core types of XSLT
are "string"  "node-set"  and I think "Xpath".  Usage of mythical type 'object' 
is signaling ... not ideal ... places in XSLT design. 

That's what I will like to get changed. The current semantics of document()
function.  Not that it really hurts me ( I'm anyway not using anything except  
document(URI) ) - that's why  it comes last in the list.

Rgds.Paul.

PS.  

For the sake of good design "shortcuts" should be thrown away from the core, 
but unavoidable entities should get into the core. 

That's why I'm not asking for  xsl:for $i= 0, 10 in the core - 
I can always implement it as :  <xsl:for-each select="my:range(1,$counter)"/>

Also I can easily implement the shortcut part of document() in XSL itself.

But I can not implement  saxon:evaluate as extension function, if the core 
has no support  for 'string'  -> Xpath conversion.



 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.