[Bug 10683] [XQ1.1] Use of "none" for default element/function namespace


--- Comment #3 from Jonathan Robie <jonathan.robie@redhat.com> 2010-09-28 14:44:13 UTC ---
We've changed this convention several times over the years, the current WD
reflects that history.

The Namespaces Rec (http://www.w3.org/TR/REC-xml-names/) says "For a name N
that is not in a namespace, the namespace name has no value" and uses this
formula in other places.

We currently use phrases like "non-null namespace URI", e.g. 

> Every user-defined function must be in a namespace--that is, every declared
> function name must (when expanded) have a non-null namespace URI 
> [err:XQST0060].

Whatever terminology we use, we should create a definition that links it to the
equivalent concept in the namespaces specification. We can borrow language from

> If there is a default namespace declaration in scope, the expanded name 
> corresponding to an unprefixed element name has the URI of the default 
> namespace as its namespace name. If there is no default namespace declaration 
> in scope, the namespace name has no value. The namespace name for an 
> unprefixed attribute name always has no value. In all cases, the local name
> is local part (which is of course the same as the unprefixed name itself).

It's clumsy to say that the namespace name of the QName of a function has no
value. We currently speak of functions that are "in no namespace" - we could
simply define that phrase. 

Definition:  A name is *in no namespace* if the namespace part of its expanded
name has no value, as defined in [XMLNames]. A function, element, or attribute
is *in no namespace* if its name is in no namespace.

Definition:  A function, element, or attribute is *in a namespace* if its name
is in in that namespace, as defined in [XMLNames].

We should definitely reduce the number of conventions for describing this one

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 Tuesday, 28 September 2010 14:44:16 UTC