This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT V 1.1
----- Original Message -----
From: David Carlisle <davidc@nag.co.uk>
> > 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