[Bug 7092] [FO] Order of prefixes ambiguous for fn:in-scope-prefixes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7092





--- Comment #3 from Michael Kay <mike@saxonica.com>  2009-12-11 23:15:25 ---
Discussion in meeting 419 led to this action:

ACTION A-419-01 Michael Kay to propose resolution to bug 7092. Define the
function in-scope-prefixes in terms of properties in the data model. Need to
check that XDM has the appropriate non-uniqueness constraint. And to handle
the inconsistency with the language documents.

What we identified was that the current description of the function was weak in
that it didn't tie up with anything in the data model. For example, if the data
model says that prefixes are unique, then the function description should not
need to repeat this.

The relevant accessor in the data model is dm:namespace-bindings, defined thus:

http://www.w3.org/TR/xpath-datamodel/#dm-namespace-bindings

"The dm:namespace-bindings accessor returns the dynamic, in-scope namespaces
associated with a node as a set of prefix/URI pairs, using an
implementation-dependent representation."

Curiously, the function prototype gives the result type as xs:string*. How this
sequence of strings is used to represent a set of pairs of strings is anyone's
guess - but I sympathise with the author's problem.

Describing it as a "set of prefix/URI pairs" does not in itself say that there
cannot be two pairs with the same prefix (mapped to different URIs).

Section H.7 repeats that in the case of element nodes, the accessor returns a
set of pairs, but curiously for other kinds of node it returns not an empty set
but an empty sequence. (But F+O invokes the accessor only for element nodes).

The accessor in the case of element nodes is defined in terms of the
"namespaces" property of the element node, but the spec actually says very
little about what that property is. Sometimes it appears to be a set of
namespace nodes, sometimes it appears to be a set of prefix/URI pairs. Perhaps
the ambiguity is deliberate?

Consistency constraint 13 in the description of element nodes (6.2.1) gives up
talking about the namespaces property entirely, and instead talks about
namespace bindings and namespace nodes.

I can't find any constraint in the data model that the namespaces of an element
must all have distinct prefixes. (Equally, I can't find a constraint that the
attributes have distinct QNames.)

Generally, I'm obliged to conclude that for 2.0, the data model does not
provide a very solid foundation for defining this function, and we are
therefore better off patching it up with sticky tape. Perhaps we can do better
in 2.1, but it will need a thorough rewrite of the way namespaces are described
in XDM, taking into account the above input.

So my proposal for a 2.0 erratum, as a minimum fix for this bug report, is to
change the specification of fn:in-scope-prefixes as follows:

Replace the current text:

<old>
Summary: Returns the prefixes of the in-scope namespaces for $element. For
namespaces that have a prefix, it returns the prefix as an xs:NCName. For the
default namespace, which has no prefix, it returns the zero-length string.
</old>

by

<new>
Summary: Returns the prefixes of the in-scope namespaces for $element.

The function returns a set of strings, corresponding to the prefixes of the
in-scope namespace bindings for $element, as delivered by the
dm:namespace-bindings accessor [DM]. 

For a namespace binding that has a prefix, it returns the prefix as an
xs:NCName. For the default namespace, which has no prefix, it returns the
zero-length string.

The result is represented as a sequence of strings containing no duplicates, in
implementation-dependent order.

Note: the result will always include the string "xml", since a binding for this
prefix is always in scope. It will include the string "" (representing the
default namespace) only if there is a default (non-empty) namespace in scope
for $element.
</new>

with corresponding changes to F+O 1.1 until such time as a more solid
description is in place in XDM.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 11 December 2009 23:15:27 UTC