Re: Name classes

[James Clark <jjc@jclark.com>]

> I have a question about the design of name classes.
> What is the design criteria behind the current spec?
>
> name-class ::= <t:name ns="namespaceURI"> NCName </t:name>
>  | <t:anyName/>
>  | <t:nsName ns="namespaceURI"/>
>  | <t:choice> name-class name-class </t:choice>
>  | <t:difference> name-class name-class </t:difference>

I considered amongst other things

- wildcards in XPath
- what XML Schema can express
- what the XML Query Algebra can express
- what is needed to write a TREX pattern for XSLT
- what is needed to write a TREX pattern for XHTML
- what is needed to support RELAX semantics

> There are other possibilities.  For example, simpler designs
> are:
>
> 1) URI+localName pairs only
> 2) URI+localName pairs and <anyName> only
> 3) URI+localName pairs, <anyName>, and
>    <nsName namespaces="namespaceURI1 namespaceURI2 namespaceURI3"/> only

I found that any solution that didn't use a nested structure with a set of
primitives and a set of operations to combine them became messy fast.

In particular, I believe it is necessary to support

- any namespace (including null) other than a particular namespace

- any non-null namespace other a particular namespace

- any non-null namespace

- just the null namespace

- a particular namespace

- any namespace at all

Also I wanted to be able to support lax validation (eg the RELAX 1 semantics
for attributes):

<element name="foo">
   <optional>
      <attribute name="bar"><data type="xsd:int"/></attribute>
   </optional>
   <optional>
      <attribute name="baz"><data type="xsd:int"/></attribute>
   </optional>
   <zeroOrMore>
       <attribute>
           <not>
              <choice>
                  <name>bar</name>
                  <name>baz</name>
               </choice>
            </not>
         </attribute>
     </zeroOrMore>
</element>

eg you can have any attribute but any bar or baz attribute must be of type
xsd:int.

> On the other hand, we can introduce more powerful primitives.  For
> example:
>
> 4) (URI, Unicode regular expression) pairs
> 5) (URI, Unicode regular expression) pairs and <nsName ns="namespaceURI"/>
> 6) <intersection> on top of 3)
> 7) boolean operations on top of 4) or 5)
>
> Certainly, Unicode regular expressions are useful.  For examplem, I
> might want to allow all HIRAGARA-KATAKANA-KANJI attributes and they
> specify that their contents are
ASCII-HIRAGANA-KATAKANA-KANJI-PUCNATIONMARKS.

That seems fairly clearly on the wrong side of the 80/20 line.  It's not
needed for any of the things I considered.

Note that the current design is almost identical in functionality to
namesets in the current (internal) XML Schema Formal Description draft.   I
think similarities with XSFD are a good thing.

James