search

qt4cg / qtspecs

QT4 specifications
https://qt4cg.org/
Other
28 stars 15 forks source link

Default element namespace in XQuery: interaction of 'fixed' and '##any' #1479

Open michaelhkay opened 3 weeks ago

michaelhkay commented 3 weeks ago

In §5.14 we document two changes to "declare default element namespace":

  1. The [default namespace for elements and types] can now be declared to be fixed for a query module, meaning it is unaffected by a namespace declaration appearing on a direct element constructor. [citation missing - should be issue #65, PR #753]

  2. The [default namespace for elements and types] can be set to the value ##any, allowing unprefixed names in axis steps to match elements with a given local name in any namespace. [Issue #296 PR #1181]

We don't discuss how these two options interact. Are they completely orthogonal?

The description of ##any says its effect is that "an unprefixed name appearing in any other context where an element or type name is expected is treated as being in no namespace." This deserves a mention in the rules for direct and computed element constructors.

In §2.2.1 we have added the statement: The statically known namespaces may include a binding for the zero-length prefix; however, this is used only in limited circumstances because the rules for resolving unprefixed QNames depend on how such a name is used.

It's not clear how such a binding can come into existence. It can't be done using any of the prolog declarations that bind a prefix. And under the current rules, I don't think it can be done using a namespace declaration attribute on a fixed element constructor. Perhaps it was the intent that xmlns="abc" would do this if "fixed" is set, but that's not the case currently.

Section §4.12.1.2 Namespace Declaration Attributes could do with a "changes" section explaining what has changed.

In §4.12.1, Direct Element Constructors, we say "If the element name has no namespace prefix, the namespace binding for the zero-length prefix in the [statically known namespaces] is used; if there is no such binding, the element name will be in no namespace." That can't be right, there's no mention of the default element/type namespace at all.

In §4.12.3.1 Computed Element Constructors, the same problem arises for a bare unprefixed NCName, but for a dynamically-computed name, we use the default element/type namespace.

michaelhkay commented 3 weeks ago

I wrote:

Also: I think that we would agree that <e xmlns="e.com"/> should create an element in namespace e.com, regardless of the setting of the default namespace for elements and types? That's not the position in the current spec.

That one seems fairly easy to fix, but fixing <e xmlns="e.com"><f/></e> seems a bit more difficult.

I was wrong. This does work. But the fact that I was misled shows how absurdly complex this all is.