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: Issue: are <optional>, <oneOrMore>, <zeroOrMore> verbose?


It won't surprise you to learn that I like things as they are. Here are my 
reasons:

1. I dispute the metric according to which:

<optional><attribute name="foo"/></optional>

is more verbose than

<attribute name="foo" occurs="optional"/>

Why is an element node plus an attribute node less verbose than two element 
nodes?  Are we counting characters here?  If that's the case, then perhaps 
we should change to <opt>, <plus>, <star> (just kidding).

2. It would complicate the spec:

(a) It would seriously uglify the simple syntax (in Section 5 of the spec). 
Instead of

| <oneOrMore> nonEmptyPattern </oneOrMore>
| <group> nonEmptyPattern nonEmptyPattern </group>

we would have

| <group occurs="oneOrMore"> nonEmptyPattern </group>
| <group> nonEmptyPattern nonEmptyPattern </group>

(b) The full syntax would become more complicated. In the grammar in 
section 3, in the pattern production, we would have to add an attribute to 
18 or so of the choices.

(c) The transformation rules would become more complicated.

3. RELAX NG provides a number of operators that operate on one or more 
patterns to produce a new pattern.  At the moment all such operators are 
consistenly expressed as an element. I believe this consistency contributes 
both to ease of learning and ease of implementation.  With the proposed 
change, we would be giving special treatment to three operators.  Why is it 
right to treat oneOrMore as an attribute but list, say, as an element? 
They are both unary operators on patterns.  Surely they should be given a 
consistent syntactic treatment.

4. In W3C XML Schema, although the concrete syntax uses attributes, at the 
component level the repetition is a separate component (a particle).  This 
reflects the fact that conceptually a oneOrMore/zeroOrMore/optional 
operator is logically separate from the pattern to which it is applied. In 
RELAX NG, we don't have a separate component layer; rather we use a 
simplified form of our syntax.  I believe this is a very important 
simplifying factor in the spec. However, to make this work well, we need 
the concrete syntax to cleanly reflect the conceptual structure.  I believe 
using attributes for occurrence operators would be a step backwards in this 
respect.

--On 05 July 2001 16:30 +0900 Murata Makoto <mura034@attglobal.net> wrote:

> Currently, to declare optional attributes, we write
>
> <optional>
>   <attribute ..>
>   </attribute>
> <optional>
>
> To declare a collection of many optional attributes, we write
>
> <define name="commonAttributes">
> <optional>
>   <attribute ..>
>   </attribute>
> <optional>
> <optional>
>   <attribute ..>
>   </attribute>
> <optional>
> ...
> <optional>
>   <attribute ..>
>   </attribute>
> <optional>
> </define>
>
> Isn't this verbose?
>
> Quite a few people in the XML Schema WG think that elements for */+/? are
> too verbose and have chosen "maxOccurs"" and minOccurs".  RELAX Core has
> chosen  "occurs".
>
> Cheers,
>
> Makoto
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: relax-ng-request@lists.oasis-open.org
>
>






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


Powered by eList eXpress LLC