Re: QNames

[MURATA Makoto <mura034@attglobal.net>]

James Clark wrote:

>I would therefore suggest not using QNames to identify datatypes. Instead,
>add an additional inherited attribute "datatypeNamespace" which can be
>specified on any element (similar to the "ns" attribute).  The type

This looks fine to me.

James Clark wrote:
>Element and attribute names appear in documents as QNames; this makes it
>natural (to me at least) for patterns to also use QNames for element and
>attribute names. If a RELAX NG implementation is going to support the XML
>Schema QName datatype, I don't see how it can avoid needing access to the
>in-scope namespaces. I therefore don't see any advantage in disallowing use
>of QNames for element and attribute names.

Probably, I'll lose.  But I would like to have alternative proposals and criterias 
for turning the down on the record.

As everybody knows, I dislike qualified names as values (as opposed to qualified 
names as element or attribute names).  Such use of qualified names was never blessed 
by the XML Namespace Rec.  If it is used, we are forced to notify application 
programms of in-scope declarations, thus destroying the layering between parsing 
and application programs.  Renaming of prefixes will become possible without knowing 
datatypes of values.

It is true that element and attribute names appear as QNames.  A namespace-aware 
parser can always translate them to URI-localName pairs.  However, use of QNames 
as attribute values for declaring element or attribute is different.  
They can be translated to URI-localName pairs only by RELAXNG-aware programs.

I am not sure if RELAX NG will always support QName.  If I make a subset of 
XML Schema Part 2, I will definitely get rid of QName as well as datatypes for 
date and time.  Also, different libraries (e.g.,  datatype libraries by 
David RR Webber) will be in use.

Here are three other possibilities.

1.  Always spell out the URI or use inheritanace of the ns attribute

Yes, this is verbose and error-prone.   But this works in some cases:

	Case 1: we use namespaces rarely 
	Case 2: inheritance of the ns attribute is good enough
	Case 3: we will later introduce a mechanism like RELAX Namespace,

2. Use internal parsed entities for representing the URI

<!DOCTYPE element 
[<!ENTITY e "http://www.example.com">]>

<element name="addressBook" ns="&e;">
  <zeroOrMore>
    <element name="card" ns="&e;">
      <attribute name="name" ns="&e;"/>
      <attribute name="email" ns="&e;"/>
    </element>
  </zeroOrMore>
</element>

I am not a fan of entities (especially external entities), but I prefer 
entities to qnames.

3.  The proxy attribute 

1) Namespace declarations

A grammar element begins with namespace delclarations (for the lack of a better name).
A namespace declaration declares a namespace URI and attaches a proxy to it.  

E.g., 

<grammar>
<namespace name="http://www.example.com" nsproxy="e"/>
<start>
<element name="addressBook" nsproxy="e">
  <zeroOrMore>
    <element name="card" nsproxy="e">
      <element name="name" nsproxy="e">
        <text/>
      </element>
      <element name="email"  nsproxy="e" >
        <text/>
      </element>
    </element>
  </zeroOrMore>
</element>
</start>
</grammmar>



Cheers,

Makoto