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: <anyNameExcept> and <anyNsNameExcept> rather than<difference>


I would like to propose a modification to Murata-san's proposal.  I think
Murata-san's proposal has significant advantages, but there is one aspect
that I strongly dislike.  We have three concepts:

a) any name

b) any name with a particular namespace

c) exclusion/difference; taking a set of names and excluding another set of
names from it

In RELAX NG at the moment we have one element for each of these concepts.
With Murata-san's proposal, we lose this orthogonality: we have an element
for (a), an element for (b), an element for (a)+(b) and and element for
(a)+(c).  This is bad because if we want to make (c) work with something
else (like strings), we have to introduce yet another element.  In my view,
this makes the language more complicated and harder to use.

I would therefore propose the following (relative to the current spec):

1) Drop <not>

2) Drop <difference>

3) Add <except> as an optional child of <nsName> and <anyName>; <except> has
one or more name classes as children. Thus

<difference>
  <anyName/>
  <name>foo</name>
  <name>bar</name>
</difference>

becomes

<anyName>
  <except>
    <name>foo</name>
    <name>bar</name>
  </except>
</anyName>

<not>
  <choice>
    <nsName/>
    <nsName ns=""/>
  </choice>
</not>

becomes.

<anyName>
  <except>
    <nsName/>
    <nsName ns=""/>
  </except>
</anyName>

<difference>
  <nsName/>
  <name>foo</name>
  <name>bar</name>
</difference>

becomes

<nsName>
  <except>
    <name>foo</name>
    <name>bar</name>
  </except>
</nsName>

As with Murata-san's proposal the grammar for name classes can prohibit
silly things that are almost certainly mistakes like:

<anyName>
  <except>
    <anyName/>
  </except>
</anyName>

4) Allow <data> to contain an optional <except> element; in this context the
<except> element would contain one or more patterns.

<attribute name="version">
  <data type="decimal">
    <except>
      <value>1.0</value>
    </except>
  </data>
</attribute>

or

<attribute name="base">
  <data type="QName">
    <except>
      <value type="QName">double</value>
      <value type="QName">float</value>
      <value type="QName">boolean</value>
      <value type="QName">string</value>
    </except>
  </data>
</attribute>

or

<attribute name="foo">
  <data type="string">
    <param name="maxLength">42</param>
    <except>
      <data type="decimal"/>
    </except>
  </data>
</attribute>

The key and keyRef attributes should probably be prohibited inside <except>
inside <data>.  We can discuss further exactly what would be allowed inside
<except> inside <data>: certainly elements and attributes should not be.

James









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


Powered by eList eXpress LLC