[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath and XPattern (was Re: More on taming SAX)
* Jeff Rafter <lists@j...> [2004-12-24 10:29]: > >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. I was wondering... 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? -- Alan Gutierrez - alan@e...
|
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
|