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: unambiguity constraint


> James Clark wrote:
>
> > > Is this basically "single type" extended so that name classes
> > > can be handled correctly?
> >
> > Don't  understand the question.
>
> I call a tree regular grammar is "single type" if we can uniquely
> determine the type of an element or attribute from its name and type of
its
> parent element.  If we also take the types of elder sibling elements into
> consideration, we have a different class of grammars "restrained
competition".
> In other words, "single type" is similar to XML Schema.

By type, do you mean to include complex types as well as simple types?

Intuitively, the constraint my algorithm imposes is that for any text node
you must be able to tell whether it is a key or keyref and what kind of key
or keyref it is just by considering the names of the ancestors of the text
node (including attribute as an ancestor).

My algorithm doesn't care about complex types.  You can be as ambiguous as
you like as far as complex types are concerned.  For example, the following
is fine:

<grammar>

<start>
  <choice>
      <element name="y">
          <zeroOrMore>
              <ref name="x"/>
          </zeroOrMore>
      </element>
      <element name="y">
          <zeroOrMore>
              <ref name="x"/>
          </zeroOrMore>
          <element name="z"><empty/></element>
      </element>
</start>

<define name="x">
   <element name="x">
      <data type="xsd:string" key="id"/>
   </element>
</define>

</grammar>

James






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


Powered by eList eXpress LLC