Re: XSLT V 1.1

[Paul Tchistopolskii <paul@xxxxxxx>]

----- Original Message ----- 
From: David Carlisle <davidc@xxxxxxxxx>

> > So what's a problem? If you don't like to write 
> > 
> > <mumble href="some/xxx.xml"/>
> > 
> > <xsl:template match="mumble">
> > <xsl:apply-templates select="document(@href)"/>
> > </xsl:template>
> 
> 
> I don't like to write that as that finds some/xxx.xml relative to the
> stylesheet. (or did you man "some" here to be absolute?)

??? My proposal says that document() is resolved relative
*not* to the stylesheet. This is the whole point! 

There is no need to resolve document relatively to the 
stylesheet - only for special cases ( lookups / 'no file' )
this is needed. For those special cases I give you the 
second parameter of 'my' document() with "" hack. 
"" is not my hack.  It is current XSLT hack. 
If you don't like it - let's replace it with $argv0 - 
both things are OK with me. ;-).

Because <mumble> is in the XML input  - document()  will 
be resolved relative to URI of XML input !
 
> > You can write:
> > 
> > <mumble href="xxx.xml"/>
> > 
> > <xsl:template match="mumble">
> > <xsl:apply-templates select="document(@href, 'some')"/>
> > </xsl:template>
> 
> I don't like to write that as that puts "some" in the stylesheet but the
> whole point is that it varies depending on which mumble node in the
> document is being processed, and currently there is no way to determine
> 'some' from the stylesheet because the URI are not exposed to xpath.

Well... As I said before : $argv0 could be used instead of  ""
( this also answers your claim about "" being not 
acceptable by W3C RFC about URI. ) I mean that 
replacing "" hack with  $argv0 gives the access to URI.

My design *is* supporting the usecase you are providing.

If I have 

/dir/book.xml

<mumble href="some/chapter.xml"/>

/dir/some/chapter.xml

And I invoke 

xslt /dir/book.xml transform.xsl

And 

transform.xsl contains:

<xsl:template match="mumble">
    <xsl:apply-templates select="document(@href)"/>
</xsl:template>

because document will be resolved relatively to 
/dir/book.xml  ( not in current XSLT of course!!!! )

document() will load   /dir/some/chapter.xml

If you mean some other usecase - could you please show it to me?

> > What's the problem ?
> Neither of your suggestions provide the functionality of resolving a
> relative URI reference relative to the URI of a particular node in the
> source.

There is some misunderstanding. Your usecase is perfectly solved 
by my design, or I'm missing something. Sorry if I'm missing 
something. 
 
> > I'm fine with your solution or with *any* other solution which will 
> > turn document() monster into something simpler. 
> 
> well one assumes that even with the extra functions that I suggested
> that document() will keep its semantics for reasons of compatibility
> if nothing else, so you'll have to learn to live with the monster
> (perhaps in 2.0 you can keep it caged though:-)

Usually 'backward compatibility' or 'legacy'  is the last excuse 
used for protecting bad design solutions. 

If the only drawback of my document() is that it is 
'not backward compatible' - this is one situation. 

If there is other rationale behind current 'document' - let us reveal 
that rationale ( with some usecase, I mean ) ?

Combining multiple documents 'on-the-fly', masquerading 
lack of RTF->nodeset on-the-fly conversion ( the 
third  semantics document() has ) is almost crazy idea, 
I think. When RTF->nodeset on-the-fly conversion 
will be in the XSLT core ( and it seems that it *will* be ) - 
I think this point  will become obvious. 

If there is some argument for *that* part of document()  
( yeah - document() is a monster with 3 heads ;-) - 
I'l like to see a usecase.

I started the thread, assuming that somebody is protecting 
that third 'head' of document(), but I was wrong - there was 
an attempt to protect the second 'head' ;-) 

Let poor ill document have only one 'head' : 
load something identified by URI into node-set. ;-)

Rgds.Paul.

PS. The last but not the least. document() is part of 
XSLT , but *not* the part of XPath. This is important. ;-)



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