[
Lists Home |
Date Index |
Thread Index
]
Jeff Rafter wrote:
>> Then people could read up on it, rather than post messages like "I
>> heard through the grapevine that predicates generally don't work with
>> streaming". Then again, I suppose, it's fun to do analysis from
>> scratch. Ah well, whatever it is, it'll be good to see streaming
>> processors!
>
>
> I said what I said after reading the latest STX spec and only in the
> context of this discussion (which is "taming SAX"). I have to agree
> with Uche in saying that STXPath is very nice-- but may not be exactly
> what we are shooting for. Surely predicates are viable in many cases
> in partial scans such as:
>
> <foo>
> <bar>
> <baz/>
> </bar>
> <bar test="foo">
> <baz/>
> </bar>
> </foo>
>
> /foo/bar[@test="foo"]/baz
>
> But when considering /foo/bar[baz3="test"]/baz1
>
> <foo>
> <bar>
> <baz1/>
> <baz2/>
> <baz3>test</baz3>
> </bar>
> </foo>
>
> This predicate's value cannot be ascertained at the point of the baz1
> startElement event in a single event look ahead model. At least that
> is what I heard through the grapevine.
Ooh. Thanks, Jeff. You clarified a bit of my thinking for me. In a
previous post I was talking about looking at restrictions on axes, but I
was only thinking of
/foo/bar[baz3]/baz1
Which *does* work for one event look-ahead, not
/foo/bar[baz3="test"]/baz1
Which, of course, as you say, doesn't.
So I started thinking of some more complex formula, say "namespace,
prefix, local name and attributes available for child node with
position() = 1, but no other properties (e.g. no string value)". But
that all gets too gnarly.
So can we actually express what we want as an actual XPath subset?
Let's say we define:
1) an operation on an XML object that converts it to a sequence of
abstract events as specified in SAX 2
2) an operation to define an XPath context in terms of all SAX event
from the start of the sequence to a current event
Is there a way from this to formally specify a subset of XPath so that
in order to evaluate an expression at any current event, you never need
more than N lookahead from the current event ?
I think it's possible, and if so, this is exactly what we need. And I
agree, of course, that STXPath is not quite it.
I think it would be nice to define such a spec so that N was indeed a
true variable, and that an implementation could say "we support XPattern
fully with N=3" or whatever, but that might be more difficult than just
giving one or two choices for N in the spec (probably [0, 1]).
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-xmlcss-i.html
Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-xml.html
Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286
UBL 1.0 - http://www-106.ibm.com/developerworks/xml/library/x-think28.html
Use Universal Feed Parser to tame RSS - http://www.ibm.com/developerworks/xml/library/x-tipufp.html
Default and error handling in XSLT lookup tables - http://www.ibm.com/developerworks/xml/library/x-tiplook.html
A survey of XML standards - http://www-106.ibm.com/developerworks/xml/library/x-stand4/
The State of Python-XML in 2004 - http://www.xml.com/pub/a/2004/10/13/py-xml.html
|
