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

"David A. Lee" <dlee@calldei.com> 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:

  http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/

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

Starting in November at

  http://lists.w3.org/Archives/Public/xproc-dev/2008Nov/0055.html

continuing in December at

  http://lists.w3.org/Archives/Public/xproc-dev/2008Dec/0011.html

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,
                                          norm

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