Re: MicroXPath

I've since made a GitHub project for MicroXPath:
https://github.com/uogbuji/MicroXPath

On Sat, Jul 9, 2016 at 8:35 AM, Uche Ogbuji <uche@ogbuji.net> wrote:

> On Sat, Jul 9, 2016 at 4:16 AM, Michael Kay <mike@saxonica.com> wrote:
>
>> >After adding a few more features here and there I realized that I should
>> just implement something more rigorous, so I started to reason about how a
>> proper MicroXPath might look. Why not start with the great simplicity of
>> XPath 1 but borrow a few of the neat tricks from XPath 2+ (read sequences)?
>>
>>
>> I'm missing any sense of what the guiding design principles are.
>>
>
> There's a bit of that in the paper. They're pretty much the same guiding
> design principles as XPath 1's, what's changed are some details informed
> from experience implementing and using the language. However, you say some
> things below that inspire me to expand on my design ideas a bit.
>

Articulated in the spec now

https://github.com/uogbuji/MicroXPath/blob/master/spec.md



> Why are you doing regular expressions differently from the way XPath 2.0
>> does them, for example?
>>
>
> I took regex directly from EXSLT, largely because I had implementations
> thereof I could readily plug in. That's something I'll have a look at.
>

Changed to XPath 2 functions, which seem to have looked to EXSLT as
inspiration, anyway.



> I think it's definitely important that the language should be relationally
>> complete (i.e. allow you to do arbitrary joins), and that requires range
>> variables.
>>
>
> With regard to accessing collections of nodes, largely to feed a host
> environment to do the heavy lifting, could you give some example use cases
> where the lack of range variables is a major problem? I should point out
> that I had written the following in the paper:
>
> "XPath 2.0/3.0 range expressions are not supported, but there are core
> functions to provide similar features."
>
> But I forgot to add those functions to the outline, or to implement them.
> The most likely reason is that my experience doesn't lend urgency to that,
> but it's certainly something I'll rethink. I'll have another look at some
> of the XPath 2/3 use-cases.
>

Added range() as a function, and from what I can see of use-cases in the
XPath 2 & 3 specs, that's powerful enough.



> If you're aiming for maximum power with minimum syntax then I think you
>> definitely want a basic set of functional programming primitives: the
>> ability to define functions and use them to map and filter sequences. With
>> that capability you can actually drop an awful lot of XPath 2.0 extensions
>> without losing much.
>>
>
> I'm not really aiming for all the power of XPath 2. Again much of that
> isn't needed in my experience, where I'm largely using XPath as a
> convenience for real work done in C, Javascript, Python, or Go (my own
> personal mix). That said I did come very close to adding most of EXSLT's
> Dynamic module [1]. In the end I thought: could that be done without? and
> concluded: yes. Worth a rethink, and another look at XSLT 2's approach.
>

Decided against functions as first-class objects. I'm happy to leave that
to the host environment, and use dynamically evaluated strings for the
quick-and-dirty cases which do come up (e.g. from examples in XPath 3 specs
and elsewhere). Again viz EXSLT.



> If you're starting from scratch, I've always felt that redefining axes as
>> functions and node-tests as predicates ought to give some mileage in terms
>> of reducing the number of concepts; perhaps use the concept of "abbreviated
>> syntax" to map following-sibling::x to following-sibling(.)[name(.)='x'].
>>
>
> Interesting. My first reaction is that the basic navigation of node trees
> is at the heart of XPath, and has enough conceptual heft to warrant its own
> syntax. I guess I'd rather keep that degree of complexity and leave out
> others.
>

Decided that the one place where syntactic sugar really makes sense is in
navigating nodes, so left XPath 1 axes as is.



> The way that XPath 2.0 extended "/" to allow atomic values on the right
>> but not on the left has always seemed deeply unsatisfactory, and I'm not
>> sure how you are tackling that problem. You seem to have extended "|" to
>> apply to atomic values, and to have extended the concept of document order
>> to be an ordering over all items, which might be the answer: you can then
>> have "!" as a simple map/apply operator, and "/" to mean "!" with ordering
>> and deduplication of the result, but with no constraints on the type of the
>> operands.
>>
>
> Yes, I think you've divined that I chose to solve as much of that problem
> as seemed pragmatic to me. Using "|" as a more universal ordering was a key
> A-HA moment for me in terms of how to reconcile sequence wit the heart of
> XPath 1. Your thoughts on "!" and "/" are intriguing, and I'll be thinking
> about that as I ponder the list/functional processing as mentioned above.
>

Decided against syntactic sugar for "!" vs "/" (a bit too perl-ish for my
taste, to put it one way). But added the map function (which I'd intended
to before, but omitted to).

A lot of other clean-up, etc., and broadened the implementation (also put
it to work in some experimentation derived from real work).

Thanks again!


-- 
Uche Ogbuji                                       http://uche.ogbuji.net
Founding Partner, Zepheira                  http://zepheira.com
Author, _Ndewo, Colorado_                 http://uche.ogbuji.net/ndewo/
Founding editor, Kin Poetry Journal      http://wearekin.org
http://copia.ogbuji.net    http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji