[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Are we losing out because of grammars?
- From: Norman Walsh <ndw@nwalsh.com>
- To: xml-dev@lists.xml.org
- Date: Thu, 01 Feb 2001 16:06:27 -0500
/ James Clark <jjc@jclark.com> was heard to say:
| It's not in general easy, unless you restrict the grammar. For example,
| consider the following TREX pattern:
I'm confused in a couple of ways.
| <element name="x">
| <zeroOrMore>
| <element name="y">
| <attribute name="z">
| <data type="xsd:string"/>
| </attribute>
| </element>
| </zeroOrMore>
| <element name="y">
| <data type="xsd:integer"/>
| </element>
| </element>
|
| If I'm in an "x" element and I get a "y" element with a "z" attribute
| that is a legal lexical representation of an integer, I can't tell
| whether to type that attribute as an "xsd:integer" or an "xsd:string"
There's only one z attribute in your example, did you mean for both y's
to have z attributes with different types?
| unless I lookahead and see whether it's the last element "y" element in
| the "x". The TREX implementation works on a stream of SAX events, so
| this is a big complication.
I'm a little confused by this example. I would have thought that the
validator had to look ahead anyway in this case.
I thought that the model was to find a matching TREX element
definition for each element in the instance. If you don't look ahead
to see if you've got the last y, how can you pick the matching
definition?
If you'd said
<element name="x">
<zeroOrMore>
<choice>
<element name="y">
<attribute name="z">
<data type="xsd:string"/>
</attribute>
</element>
<element name="y">
<attribute name="z">
<data type="xsd:integer"/>
</attribute>
</element>
<choice>
</zeroOrMore>
</element>
I think I'd have been less confused :-)
Be seeing you,
norm
--
Norman.Walsh@East.Sun.COM | If you run after wit you will succeed in
Technology Development Group | catching folly.--Montesquieu
Sun Microsystems, Inc. |