- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 26 Aug 2000 11:53:47 +0100
- To: Murata Makoto <mura034@attglobal.net>
- Cc: xmlschema-dev@w3.org, connolly@w3.org, koike@mmp.cl.nec.co.jp
Murata Makoto <mura034@attglobal.net> writes: > > Several people have pointed that out, but I don't see anyone > > explaining why. There is a reason... > > I do not think your argument holds water. > > > Suppose your scheam had some appinfo that guided processing: > > > > <element name='A'> > > <complexType content='elementOnly'> > > <element ref='test:B' minOccurs='0' maxOccurs='unbounded'> > > <annotation><appinfo>turn left</appinfo></annotation> > > </element> > > <element ref='test:C' minOccurs='0'/> > > <element ref='test:B' minOccurs='0' maxOccurs='unbounded'> > > <annotation><appinfo>turn right</appinfo></annotation> > > </element> > > </complexType> > > </element> > > > > Given <A><B/></A>, it's not clear whether one should > > turn left or turn right. > > > > The "no non-deterministic content models" restriction in > > the XML schema spec makes sure that you can always correlate > > the elements in the input with bits of appinfo (or > > other type information) in your schema. > > You do not need deterministic content models for this purpose. > You only need strongly-unambiguous content models, which can represent > any regular language. Remember that deterministic content models > cannot capture all regular languages. (More about this issue, see > Anne's paper.) > > Strongly-unambiguity: there is only one possible parsing. I agree this would be a good compromise. Note that Koike's content model is not strongly-unambiguous, however, and Dan's answer is still correct for why _that_ is a problem. ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2001, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/
Received on Saturday, 26 August 2000 06:53:53 UTC