Re: [xml-dev] MicroXPath proposal

[Michael Kay <mike@saxonica.com>]

> I got curious just how much larger.  On my system, the XPath 1.0
> document, which also documents the data model and the available
> functions, is 37 pages.  XPath 2.0 + XDM + F&  O is 367 pages.  That's
> an order of magnitude larger, rather than just "noticeably" so.

The specification of the count() function alone has increased from 15 
words to 75 - five times larger. Yet the functionality of count() has 
not changed one iota. The increase is accounted for by (a) the 
specification being a little more formal, (b) by redundancy in the 
specification, introduced in the interests of clarity, and (c) the 
addition of examples.

I don't think that the length of a specification tells you much about 
the complexity of the language; it's more a reflection of the writing 
style of the individual or committee that wrote it.

Better measures are the number of production rules in the grammar and 
the number of functions in the function library. On those measures XPath 
2.0 is probably about 3 times the size of XPath 1.0. On the other hand, 
XPath 2.0 incorporates regular expressions, and the complexity of the 
regular expression language is probably quite a bit greater than that of 
XPath itself; but they're specified by reference to an external spec - 
I'm not sure how you measure that.

Michael Kay
Saxonica

> Again, I doubt if I can write down a coherent XPath subset in 3.7
> pages, but it would be interesting to try.
>
> On Fri, Jan 14, 2011 at 9:58 PM, James Clark<jjc@jclark.com>  wrote:
>
>> The only subset of XPath 1.0 that makes sense to me is one that has the goal
>> of being able to create one path that uniquely identifies any element (and
>> perhaps attribute) in a document. Something like
>>    /foo[2]/bar[1]/baz[3]
> Well, that's something worth having for sure, and even treating
> specially, because it can be made to return a single Element rather
> than an iterator.
>
> On Sat, Jan 15, 2011 at 10:04 PM, Uche Ogbuji<uche@ogbuji.net>  wrote:
>
>> I agree with the above until the last point.  I also believe that the
>> "streamable" subset of XPath 1.0 is useful, though of course people
>> establish such a subset in several ways.  I'd say XSLT 1.0's pattern
>> language comes close enough for most uses.
> Now that's a *very* interesting idea: the path would allow / and //,
> and the legal path steps are: name, *, @name, @*, text(), and
> id(name).   That's very close to my original proposal.  But patterns
> are no simpler than XPath 1.0 for the implementor, because *any*
> expression can be a predicate in a pattern, so you end up having to
> implement the whole of 1.0 anyway.  What is the simplest set of
> predicates that could possibly work?
>