[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