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: Issue: <anyNameExcept> and <anyNsNameExcept> rather than <difference>


I propose to replace <difference> with <anyNameExcept>
and <anyNsNameExcept> while preserving expressiveness.  The suggested
syntax *looks* simpler than the current syntax, although smart guys
find the current syntax simple already.

Note: Thanks to Kawaguchi-san for his suggestion, though he does not 
really buy this new syntax.

1. Motivation

I think that nameclasses containing <differnece> look complicated.

I know that <difference> is actually not complicated.  James's
algorithm and Kawaguchi-san's normal form provide a basis for several
operations including simplification, boolean operations, and infinitcy
checking, etc.  You only have to understand these techniques or 
use a libary which implements them.


Nevertheless, I think that name classes *look* complicated and can be
changed so that they *look* simpler while preserving expressiveness
(i.e., closure under boolean operations).

Here are some examples why I think <difference> in the current syntax
is complicated.

<name>a</name> is equivalent to:




Almost any program for handling names in RELAX NG will have to
simplify such name classes.  As I said before, this is certainly
possible and arguably easy.  Nevertheless, I think that 
it *looks* complicated enough for discouraging implementors.

2. Alternative syntax

The ideas are as below:

(1) we only have to allow <anyName> or <anyNsName ns="..."> as the
    first operand of <difference>; and

(2) when the first operand of <difference> is <anyNsName ns="...">, 
    we do not have to allow infinite nameclasses as the second argument.

Here is my proposal.

name-class ::=

 | <t:anyName/>
 | <t:anyNsName ns="namespaceURI"/>

 | <t:anyNsNameExcept> name-class-literal+ </t:anyNsNameExcept>
 | <t:anyNameExcept>
     (name-class-literal | <t:anyNsName ns="namespaceURI"/>)+

 | <t:choice> name-class name-class </t:choice> 

name-class-literal ::=
   <t:name ns="namespaceURI"> NCName </t:name>  

The semantics of <t:anyNsNameExcept> and <t:anyNameExcept> 
should be obvious.

A real advantage of this syntax is the infinity check is trivial; a
name class is inifinite if and only if contains <anyNameExcept> or

I do not think that other operations such as equivalence testing and
boolean operations become really easier.

The biggest advantage of this snntax is that it looks simpler, in my 
opinion.  I think that this is important for market acceptance.



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

Powered by eList eXpress LLC