This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSLT V 1.1



----- Original Message ----- 
From: Didier PH Martin <martind@netfolder.com>


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]