Re: Underspecified interaction between node-set() and key() function

Jirka Kosek wrote:
> Hi,
> 
> it seems that description of node-set() function doesn't precisely
> specify how the output of the function should be considered when used
> together with id() and key() functions.
> 
> E.g. Saxon can evaluate key() over nodes returned from node-set()
> function as far as current node is from the node-set() result when key()
> is invoked. Saxon behaves here as if the result of node-set() is a new
> document which is covered by xsl:key index.
> 
> However xsltproc doesn't consider result of node-set() as a new document
> and key() function then fails and returns nothing.
> 
> I propose to extended node-set() function specification to state that
> result of node-set() should be considered as a new document which is
> similar to result of document() function in this sense. Then key()
> should work over nodes returned from node-set() as long as the current
> node is from the same temporal document returned by node-set().

I do agree that the behavior of id() and key() should not be impaired on
converted result tree fragments. XSLT 2.0 is explicit about this point, for
its 'temporary trees'. So I don't see any harm in making this expectation part
of the spec for exsl:node-set().

We should probably also add a note about base URIs. I suggest the following,
for now:

  Implementations should ensure that id() and key() can be used to locate nodes
  within the node-set returned by this function, provided that at the time the
  id or key function is called, the context node is a node within the set.

  This function does not modify the base URI of nodes in the result tree
  fragment when converting it to a node-set. Since XSLT 1.0 does not specify
  how the base URI of nodes in result tree fragments are determined, the
  base URI of the nodes in the converted set will be implementation-dependent.

One thing, though I'm not sure how id() is really expected to work on these
trees. I thought I'd look to see how XSLT 2.0 says to do it, but XSLT 2.0 is
unclear on this point. The way I see it, the IDs that id() needs are assigned
based on attributes being declared in a DTD as being of type ID. Well, how
does one associate a DTD with a (converted) result tree fragment or temporary
tree? I don't see how anyone could ever reasonably expect id() to return
anything when operating on such a tree, because there will never be a DTD
associated with the tree, and even if there were, it seems unreasonable to
expect the processor to parse the DTD.

Also, I'm having trouble finding where in the XPath 2.0 specs there is any
discussion of the assignment of unique IDs to nodes. In an appendix it says
"The recognition of a node as an id value is sensitive to the manner in which
the datamodel is constructed", and the data model spec says "[Node identity]
should not be confused with the concept of a unique ID, which is a unique name
assigned to an element by the author to represent references using ID/IDREF
correlation", but that seems to be the extent of it. Did I miss something?
Because of this, the fn:id() XPath 2.0 function seems to be underspecified.

I'll send these latter issues to the public-qt-comments list at the W3C and
see what they say.

-Mike