Re: with-option and other XPath Expressions - Prevent streaming from being possible (??)

"David A. Lee" <> writes:

>>I'm tempted to do a little bit of this myself. Just recognizing the
>> expressions ^\$[A-Za-z_][A-Za-z0-9_]$, ^\'.*\'$, and ^\".*\"$ would
>> probably cover 80% of the cases. (It wouldn't obviate the user from
>> oviding the explicit binding, however.)
> I thought about this for a while last week ... having the parser do
> static analysis on the xpath.
> Regex's wont hack it. 

Regexes won't catch all the possible static values, but any expression
that matches the regexes I gave above is static. And I think that'd
cover most of the cases in practice.

> And this one sticky point could be what makes it impossible (or so
> extremely difficult that it wont ever be done) to have xproc ever work
> in a streaming mode in the majority of cases.

I don't follow. How does splitting an input break streaming? The
splitter can stream, the downstream processes can stream, it's all
good. Just start a thread for each component and off you go...

> the future say someone came up with a streaming XPath library where
> you could feed it say StAX events and out would come more StaX events

My XPath 1.0 based implementation used StAX and did stream a few
components in some of the simple cases. I'm pretty sure it streamed
the splits too.

> In Conclusion
> I'd like to cast a "Formal Vote" if there is such a thing, that the
> default case be reversed.

Send a summary to the XProc comments list, please:

You don't have to repeat the whole thread, if you point to it in the archives:

Starting in November at

continuing in December at

Note that you formally object to this aspect of the spec (technically,
you should have raised the objection during Last Call, but we don't
need to stand on ceremony.)

> And that if no binding is given for with-option then the <empty/>
> binding is implied.  Not doing so, in my opinion, will have a dramatic
> negative effect on the real world usefulness of this spec and places a
> severe, unnecessary, cap on possible efficiency of implementations
> (without extraordinary efforts) for very limited potential benefit in
> syntax to users.

                                        Be seeing you,

Norman Walsh <> | To what excesses will men not go for            | the sake of a religion in which they
                              | believe so little and which they
                              | practice so imperfectly!--La Bruyère

Received on Friday, 5 December 2008 15:03:17 UTC