Re: Updated: issue qnameAsId-18

Norm:  you've done a great job on this.  One  minor suggested correction 
to [1], which currently says:

<original>
In these contexts, QNames are most often used 
to identify a particular element type; they are, 
in principal, using QNames as they were intended.

It's possible that specifications will invent 
new uses for QNames as well, using them as 
shortcuts for unique identifiers derived from 
a URI/localname pair that have no relationship 
to element or attribute types.
</original>

I suggest the second paragraph be changed to something along the lines of:

<suggested>
Other specifications use QNames as shortcuts for unique identifiers 
derived from a URI/localname pair that have no relationship to element or 
attribute types.
</suggested>

because we already have recommendations that do this.

Specifically, in the XML Schema recommendation, QNames in attribute values 
such as type="xsd:Integer" or ref="somens:myAttr" refer not to an element 
or attribute, but to an abstraction called a schema component.  The type= 
reference is to a type definition component, and the ref= is to an element 
or attribute declaration component.   This is covered in the schema rec. 
at [2], which says:

        "Schema Representation Constraint: 
           QName resolution (Schema Document) 

           For a ·QName· to resolve to a schema 
           component of a specified kind..."

So, it's clear that QNames resolve to components.  Therefore, saying "it 
is possible" seems wrong, given that we have a rec that already does this. 
 

Detailed Explanation of Schema QName References
-----------------------------------------------

Here's a concrete if somewhat unusal use case for those few who will want 
to understand the subtleties and some motivations for QName reference 
mechanisms in XML Schema (or, most of you should probably just trust me 
that QName references from a schema document are not to elements and 
attributes, and skip the rest of this note.)  In general, such references 
in XML schema are from an XML schema document to an XML schema component. 
Consider:

<schemaQNameReferenceUseCase>
Someone invents an API for creating and managing schemas.  It has methods 
like createTypeDefinition, createElementDeclaration or some such.  Using 
this API, a schema is created in memory.  This is a perfectly legal schema 
per the schema spec.  It has never existed in "<...>" XML 1.0 syntax and 
indeed is not embodied as XML Infoset(s) (though it does become part of 
the PSVI if a validation is done.)  We went to some trouble to make sure 
that such schemas have first class standing, as we expect them to be 
created dynamically by database systems, and sometimes hardwired into 
vocabulary-specific applications such as XHTML editors.

I know this is a somewhat subtle example, but consider the case where a 
schema document imports this non-document based schema, which again is 
perfectly legal.  For example, my schema documents imports XHTML, and 
we're running in a specialized XHTML editor which is using its own 
representation of the XHTML schema.   It should be clear that any QNames 
that are used to reference from the schema document to the synthetic 
schema (from my schema to an XHTML type, for example) could not possibly 
be referencing an element or attribute target, since there never were any 
element or attribute representations of the target schema.

The fact is that, even when one schema document imports a schema that is 
itself in a document, the QName references are to the components created 
from the schema document, not to the elements and attributes in the 
document.  All QName references in XML schema are uniform, and all are to 
components.  The tricky in-memory example is merely to point out that 
there exist referenceable schemas that in fact have never (and never will) 
exist in the form of elements and attributes, and we reference all schema 
components in the same manner.

There are other reasons why schema references are to components, but the 
above example is representative of the issues.
</schemaQNameReferenceUseCase>

Bottom line:  I suggest the small tweak to the otherwise excellent draft 
that Norm has written.

[1] http://www.w3.org/2001/tag/doc/qnameids.html#sec-qnames-other
[2] 
http://www.w3.org/TR/xmlschema-1/#section-Constraints-on-XML-Representations-of-Schemas

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 7 June 2002 15:10:02 UTC