RE: [xsl] Using document()

["Adam van den Hoven" <list@xxxxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx 
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Michael Kay
> Sent: October 10, 2002 1:31 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> 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