[Xpath-ng] Thoughts on work products

[Jeni Tennison]

Hi Eric,

>> The problem as I see it: XPath should be something that's usable in
>> multiple different contexts -- in XSLT, in XQuery, in schema
>> languages, in XForms, in XPointer, in DOM, etc. etc. etc. XPath 2.0
>> is so weighty (particularly because the XML Schema support) that it
>> can't be adopted wholesale into these different contexts, and
>> doesn't have easily identifiable modules, which means that we'll
>> end up with different parts being incorporated into different
>> languages in different ways. It's also a product of two communities
>> (XSLT and XQuery) with very different requirements pulling in
>> different directions which has led to some ugly compromises.
>
> I think we need to be careful here: if we include in our reqs that
> XQuery and XSLT 2.0 should be able to rely on XPath NG, there is a
> risk that we end up with something as complex as XPath 2.0 and also
> with something not backward compatible with XPath 1.0.
>
> I'd rather try to qualify the problem we're trying to solve against
> XPath 1.0 than against XPath 2.0 and in this case, we may say that
> we need something more modular and extensible than XPath 1.0.

OK. I agree we need something more modular and extensible than XPath
1.0, but I think that it took XPath 2.0 to make me realise it.

>> The goals for XPath NG should be, I think:
>> 
>>  * Simplicity
>>  * Modularity
>>  * Extensibility
>>  * Schema language independence
>>  * Backwards compatibility
>
> These are good goals!
>
> Simplicity is subjective :-) ... do we want for instance something
> as simple as XPath 1.0 or more simple than XPath 1.0?

Simplicity is *very* subjective :) I guess I really mean "elegant"
(which is even more objective!) rather than simple. I think that an
elegant language is one in which there are a few simple fundamental
rules that combine to make something that's very flexible and
powerful. There's something about looking at the problem at a deep
level, going right down to its foundations and building up from there,
rather than taking a very narrow view and fiddling with only parts of
the design at a time. Perhaps a good way of defining simplicity would
be to count the number of exceptions that are needed to describe
something.

> About modularity, we are seeing many application defining their own
> XPath subsets and XPath 1.0 doesn't really support this kind of
> things. We may want to kind of split XPath 1.0 itself into modules
> which could be combined.

Yes, I think we do.

> The requirement to have a subset that is "streamable" seems
> interesting for many applications such as STX and eventually regular
> fragmentations and Relax NG rules checking extensions I guess. That
> could also allow to define a layer on top of SAX where you would
> register callback functions matchind XPath NG patterns and this
> could be one of the core modules.

I agree that a "streamable" subset makes a good core.

> Extensibility is key and I like a lot your idea to allow the
> creation of new axis that could be used to access all kind of
> annotations.

Cool :)

> Schema language independence is also important and I would even
> suggest to be stronger than this and say that XPath NG core should
> not use any schema language (independence can be understood as "can
> work with any of them" while I think we want to express "does not
> use any of them") and add that access to schema based features
> should be provided by specific modules which should attempt to be
> schema language independent as far as possible.

Right, I agree.

> Backward compatibility is a tough one. My take on this one is that
> XPath NG should be backward compatible with XPath 1.0 except if we
> find a compelling reason to break this rule, But when I see all the
> suggestions to change the vocabulary and the concepts, I guess that
> this will be a very controversial issue.

Actually, I agree. I put backwards compatibility at the bottom of the
list precisely because I think it's more questionable. I think that
there should be a profile that is as near as dammit XPath 1.0, but
that doesn't mean that everything done in all the other modules need
to be compatible with XPath 1.0.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/