[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