Re: Are we losing out because of grammars?
/ James Clark <jjc@j...> 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@E... | If you run after wit you will succeed in Technology Development Group | catching folly.--Montesquieu Sun Microsystems, Inc. |
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format