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: [relax-ng] Re: Making ambiguous schemas deterministic

On Thu, 2002-07-11 at 15:06, Kohsuke Kawaguchi wrote:
> > Or have I missed something and is it more complex than this?
> Sometimes, even if the grammar is unambiguous, it is hard to assign
> types in a streaming fashion. Consider this:
> <start>
>   <element name="root">
>     <choice>
>       <ref name="foo1"/>
>       <ref name="foo2"/>
>     </
>   </
> </
> <define name="foo1">
>   <zeroOrMore>
>     <element name="foo"><empty/></element>
>   </zeroOrMore>
>   <element name="one"><empty/></element>
> </define>
> <define name="foo2">
>   <zeroOrMore>
>     <element name="foo"><empty/></element>
>   </zeroOrMore>
>   <element name="two"><empty/></element>
> </define>
> This grammar is unambiguous because a valid instance can only yield one
> interpretation. However, it's very hard to keep track of type assignment
> to each element.

Yep, makes me understand that there is a major issue with my suggestion
to define the rules on the simple form of the schema, ie something such

start= root
root= element root{
  ((empty|foo+), one )|((empty|foo+), two))
foo= element foo{empty}
one= element foo{empty}
two= element foo{empty}

If by "type" you mean "foo1" and "foo2", this information is lost during
the simplification of the schema! OTH if by type you mean some
annotation attached to the reference to "foo1" and "foo2" in the
complete schema, there is some hope to be able to carry this annotation
during the simplification process.

> I guess in the world out there, most of the people write unambiguous
> schema. So my feeling is that it's OK if we can guarantee that
> 1. there is a well-defined subset of RELAX NG,
> 2. the type assignment of those schemas are guaranteed to be unique, and
> 2. it can do a type assignment by a streaming processor

I have mixed feelings about the statement "most of the people write
unambiguous schema". Isn't it true only because people had to with
previous schema languages? 

I like your proposal as being a simple straightforward solution to get
align with W3C XML Schema type assignment, OTH not having to bother
about your schema being ambiguous gives so much more flexibility that it
might be worth having a look at alternative approaches preserving this


See you in San Diego.
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema

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

Powered by eList eXpress LLC