This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 4.2.6, the deref() function is defined. Part of the definition reads: 2. If the implementation recognizes R as using N supported schemes, then deref() is not required to attempt to resolve all N schemes. Its behavior in this case is implementation-defined and the set of schemes that are actually attempted may be any subset of the recognized schemes. This is subject to the following constraints: a. If deref() doesn't attempt to resolve any scheme or if none of the attempted schemes resolves, then no target is returned. I believe that the idea is that the deref() implementation performs a nested iteration over all references in the input node set and over all the schemes of each reference. First, the idea of iteration might possibly be expressed more directly; this is an editorial issue and I'll defer to the sense of the editors on it. Second, the description needs to be clearer about where the subrules (a) through (e) of item (2) apply: when they say what is returned, do they mean returned for each scheme (on a given input reference element), or for each reference element (in the given input node set), or for the call to deref()? In oral discussion today, Sandy Gao suggested that the subrules apply to each reference element. We saw two ways to make that fact clearer: either add "for each reference" or "for each reference element in the input node set" to each of the subrules (a) through (e), e.g. a. If deref() doesn't attempt to resolve any scheme or if none of the attempted schemes resolves, then no target is returned for the reference element. or alternatively put some equivalent phrase into the introductory prose of item (2) so that it's clear that it applies to the five subrules. Third, there was also some surprise in the discussion today at the claim that if one passes seven reference elements in, each of which successfully resolves to exactly one target element, one might get six elements, or just one element, back. An example or two might be useful to make clear to the reader that the word "set" here is used in a strict sense, and not as a synonym for "bunch" or "bag". Fourth, note that the concept of node sets in XPath 1.0 has been replaced, in XPath 2.0, by the concept of sequences. If we wish to avoid de-duping, we should consider describing deref as returning a sequence, not a set. (And if so, we need to be clear how the sequence is determined.)
based on 01/31 meeting marked editorial If 7 ref are passed, the resolved output set should contain anywhere between 1 and 7 nodes From IRC : <Kumar> john: proposal: in the case above, anywhere between 1 and 7 elts are returned. <Kumar> john: the above requires removing dup nodes from the output nodeset.
*** Bug 5411 has been marked as a duplicate of this bug. ***
Please review the changes made to section 4.2.6 deref() XPath Extension Function. Bulleted lists are hard to see properly in bug history. It may be easier to review the changes by looking at the spec. ------------ 4.2.6 deref() XPath Extension Function Each SML processor MUST provide an implementation of the deref() XPath extension function. This function takes a node set of elements and returns a node set consisting of element nodes corresponding to the elements referenced by the input node set. In particular, for each SML reference R in the input node set the output node set contains at most one element node. Let, I = input node set. That is, the set of nodes passed to deref() function. Let, O = output node set. That is, the set of nodes returned by deref() function. The behavior of deref() function MUST satisfy the following constraints: For each SML reference R in the input node set I: If the implementation recognizes no SML reference scheme used in the SML reference R, then no element is added to O. If the implementation recognizes R as using N supported reference schemes, then deref() is not required to attempt to resolve all N schemes. Its behavior in this case is implementation-defined and the set of reference schemes that are actually attempted may be any subset of the recognized schemes. This is subject to the following constraints: If deref() doesn't attempt to resolve any reference scheme or if none of the attempted reference schemes resolves, then no element is added to O. If at least one of the attempted reference schemes resolves to more than one target element, then 0 or 1 of the targets is added to O. If one attempted reference scheme resolves to a target different from the target resolved by another attempted reference scheme, then 0 or 1 of the targets is added to O. If one attempted reference scheme resolves and another doesn't, then 0 or 1 of the targets is added to O. If none of the above is true (that is, all attempted reference schemes resolve to the same one and only one target element, call it T), then one target element (namely, T) is added to O, if it does not already exist in O.
from: passed to deref() function to : passed to the deref() function (similarly on O=/returned by) fwiw, this section seems likely to give outside readers problems. I anticipate them trying to reconcile it with the behavior required of model validators, which is different. I am willing to let the outside review process force us there. I will present the following proposal however, so if the wg as a whole anticipates the same problem and wants to fix it now, or we punt now and demonstrate it later via the review process, we have a start at addressing it. Add the following, immediately after the heading: Note: This note is non-normative. This section describes the behavior required for a general XPath 1.0 deref() library function, and as such exhibits several significant differences from the behavior required to validate SML references during model validation. First, it can be used to successfully process instance documents whose SML model validity is unknown or invalid, although the results in this case may not be interoperable. Second, since XPath 1.0 defines no way for a function to signal erroneous input to its caller, the behavior here is specified to return results for SML references that do not obey all of the validity rules, e.g. a reference whose XPath expression evaluates to more than one node. As described in this section, such a function would be insufficient to check the validity of SML references.
Made all of the changes suggested in comment# 4.