OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Name classes

> 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">
      <attribute name="bar"><data type="xsd:int"/></attribute>
      <attribute name="baz"><data type="xsd:int"/></attribute>

eg you can have any attribute but any bar or baz attribute must be of type

> 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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC