[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