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>


Summary:  

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.

http://lists.oasis-open.org/archives/relax-ng/200105/msg00058.html
http://lists.oasis-open.org/archives/relax-ng/200105/msg00058.html

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:

<difference>
  <choice><name>a</name><name>b</name></choice>
  <name>b</name>
</difference> 

<difference>
  <anyName>
  <difference><anyName><name>a</name></difference>
</difference> 

<difference>
  <difference><anyName><name>b</name></difference>
  <difference>
    <anyName><choice><name>a</name><name>b</name></choice>
  </difference>
</difference> 

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 ::=
  name-class-literal

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

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

 | <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
<anyNsNameExcept>.

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.


Cheers,

Makoto



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


Powered by eList eXpress LLC