[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