[
Lists Home |
Date Index |
Thread Index
]
>> Say the test was /foo/bar/[baz2="test"]/baz1
>>
>> <foo>
>> <bar>
>> <baz1/>
>> <baz2>test</baz2>
>> <baz3/>
>> </bar>
>> </foo>
>>
>> If your schema stated that the children were (baz1,baz2,baz3)
>> wouldn't you have enough information to know to surrender when
>> you reached baz3?
Essentially in order to make a useful case of this (surrendering at
baz3) you would need to cache all previous events so that they could be
replayed when the predicate's boolean value was determined.
Unfortunately that solution doesn't win much against the DOM or other
tree based models.
The *trick* is to know when you reach baz1 so that you can begin doing
interesting things with the chain of events as they happen. Now, the
Schema Assisted Sipping that you mention might broaden the cases that
predicates would be useful but they are still limited. For example if
your schema asserted (as you say) that the content model of bar be
(baz1, baz2, baz3) and that baz2="test" always-- then you could
"surrender" at the point of baz1 by starting with the assumption of
validity. If the document turns out to not be valid you could raise some
special error that says essentially-- hey we assumed this was valid and
it isn't so we don't know if we reported the right thing or not.
There is still a group of solvable predicates too, like:
/foo/bar[baz2="test"]/baz3
Here the predicate's boolean value will be known before the startElement
for baz3 is reached. The question is: is it worth defining a constraint
for this in plain language or in grammar, or should predicates be nixed
entirely? If we aim for defining the constraint then I would suspect
that we will find a wealth of information on this exact subject on the
STX list (as Christian mentioned)-- but ultimately it appears that they
decided no such constraint would appear in their language. In XML
Schema's stripped down XPath, predicates are not permitted.
All the best,
Jeff Rafter
|
