Re: Comments on Namespaces 1.1 from XML Schema Working Group

This is a formal response from the XML Core WG to your comments on the
Namespaces in XML 1.1 last call working draft.

If we haven't heard from you by the end of Monday December 9th, we
will assume for the purposes of our planned CR request that you have
no objection to our resolution.

Commenter email address: cmsmcq@acm.org

> Subject: Comments on Namespaces 1.1 from XML Schema Working Group
> 
> Universal names
> 
>[...]

> The phrase "universal names", in conjunction with similar phrases
> (e.g. "universally unique" in para 8) suggests to some readers names
> which are universally unambiguous. Given a "universal name", such
> readers expect to be able to identify, without further information, a
> single object denoted by the universal name.
>
>[...]

Summary: accepted

We have rewritten much of section 1.  The paragraph in question
now reads:

  These considerations require that document constructs should have
  have names constructed so as to avoid clashes between names from
  different markup vocabularies. This specification describes a
  mechanism, XML namespaces, which accomplishes this by assigning
  expanded names to elements and attributes.

> para 8 sent -2 SEVERE:
> 
> ... The combination of the universally managed IRI namespace and the
> document's own namespace produces identifiers that are universally
> unique. ...
> 
> The term 'universally unique' is undefined and misleading. It suggests
> to some readers that the identifiers so described will or must have
> universally unique denotations (see our note on para 3), but such
> universally unique denotation is neither guaranteed nor required by
> the mechanism defined in this spec.

Summary: accepted

Again, we now refer to avoiding name clashes rather than producing
unique identifiers.

> sec 1 para 4 sent -2/-1 editorial:
> 
> ... XML namespaces differ from the "namespaces" conventionally used in
> computing disciplines in that the XML version has internal structure
> and is not, mathematically speaking, a set. These issues are discussed
> in B The Internal Structure of XML Namespaces.
> 
> These last two sentences have proven more misleading than they seem to
> us to be worth.

Summary: accepted

These sentences, along with Appendix B itself, have been removed.

> sec 1 para 9 sent 3, SEVERE:
> 
> An attribute-based syntax described below is used to declare the
> association of the namespace prefix with an IRI reference; ...
> 
> This sentences describes the syntax of namespace declarations as
> "attribute-based", but this seems incompatible with the decision on
> this matter made by the XML Core Working Group in the development of
> the XML Information Set Recommendation. 
> [...]

> [Definition: A namespace is declared using a family of reserved attributes....]
> 
> According to the infoset spec, namespaces are NOT declared using a
> family of attributes, but using namespace declarations
>[...]

Summary: rejected

The Infoset is layered on top of XML 1.x and Namespaces 1.x.  The
Namespaces spec refers to XML constructs using XML 1.x terms.  As
far as XML 1.x is concerned, namespace declarations are certainly
attributes.  Even in the Infoset, they are described as namespace
attributes.

In a future merged XML+Namespaces, we would probably remove this
anomaly, but for now namespace declarations remain a family of
reserved attributes.

> sec 1 para 8 editorial, serious:
> [...]
> 
> We have found it exceedingly helpful, both in the XML Schema
> specification and in the internal discussions of our Working Group, to
> have several different pairs of terms, which denote respectively:
>
>[...]

Summary: accepted in part

The new draft provides more, and more accurate, definitions.  In
particular "qualified name" is defined as a name subject to namespace
interpretation, with the corresponding production QName now defined as
PrefixedName | UnprefixedName.


> para 6 editorial, medium serious:
> 
> The empty string, though it is a legal IRI reference, cannot be used
> as a namespace name.
> 
> for 'cannot be' we think 'must not be' should probably be
> substituted. We think, that is, that this is a normative prohibition,
> not the statement of a fact which could be established as a logical
> consequence of rules elsewhere in the spec; we realize we may be wrong
> in this thought.

Summary: rejected

It is in fact a logical consequence of other rules, since an empty
string is interpreted as an undeclaration.

>  Section 4 Using Qualified Names
> 
> para 2 sent 1 (after production [11]) editorial, medium serious:
> 
> An example of a qualified name serving as an element type:
> 
> For "a qualified name serving as an element type" read "a qualified
> element type name" or "a qualified name serving to identify an element
> type". Element types are not identical to their names.

Summary: no longer relevant

We have replaced "element type" with "element name" throughout the
text (in some places "name" was already used).  I (the editor) believe
that the term "element type" is confusing now that we have schemas
that may assign different types to elements with the same name.

As to your more minor editorial suggestions, the editor has accepted
some and rejected others at his discretion and does not propose to
list them all here!

-- Richard Tobin, Namespaces 1.1 editor

Received on Thursday, 28 November 2002 13:37:49 UTC