-----Original Message-----
From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
[mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
Michael Kay
Sent: October 10, 2002 1:31 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: RE: [xsl] Using document()
why is it necessary to do
document('foo#bar') rather than do
<xsl:for-each select="document('foo')">
<xsl:value-of select="id('bar')"/>
</xsl:for-each>
The ONLY thing I know is that I'm not going to get anything
more complex than a bare XPointer to a node with an ID. It
could be in the input file or it could be in an external file.
To do anything like what you suggest would require a bit of
string manipulation (although granted its not that hard).
I would recommend that you do the string manipulation.
You might be able to achieve the right effect with a
URIResolver, but it
won't work on all products. There is an awkward interaction
between the
URIResolver specification and the rule that if you access the same
document twice, you must get the same root node back each time. This
puts the XSLT processor in a quandary when you do:
document('foo#john') | document('foo#mary')
See I'm not convinced that there should be a problem. If we were to
assign that to the variable $example, I would expect that it would have
two nodes in the node set. Further I would expect that
$example/ancestor-or-self::*[not(parent::*)] (assuming that would
correctly reference the root element of a node) would return a node set
of one. Further, if foo.xml is:
<root>
<ele id="john">
<ele id="mary" />
</ele>
</root>
I would expect that:
document('foo#john') | document('foo#mary')/parent::*
and
document('foo#john')/ele | document('foo#mary')
Would both return one node
Saxon solves this dilemma by not passing the fragment to the
URIResolver. This might seem unfriendly, but there is some
logic to it:
the specification for URIResolver says clearly that it is intended to
resolve a URI, not a "URI Reference", and the fragment is not actually
part of the URI. It also follows the same logic as HTML
browsers, where
the request for a URI is passed to the server, and the location of a
fragment is the responsibility of the client.
I can understand why you would do it this way. HTML has set a very
useful guideline to follow.
So it makes sense to me that URIResolver would only return the document,
not the fragment. However, the XSLT engine IS the client. Not the
ultimate one but certainly the client. We don't expect Web developers to
write JavaScript that checks the URL onLoad and scroll to the correct
position based on the fragment. I'm not sure why we should expect XSL
developers to do it.
Mind you, I don't think that document() is the right name for a function
that does this since we are not returning the document but a fragment.
If we had a function that would take a string (or a node set of text
nodes), retrieve the document (if appropriate), evaluate the fragment
(as an XPointer?) and return a node set, everyone would be happy. I
could take a string representation of a path and get a node plus I can
take a URI with a fragment (perhaps a more extensive XPointer) and get a
node set. What we'd call it, I have no idea.
Adam
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list