[Xpath-ng] Thoughts on work products

[Eric van der Vlist]

On Thu, 2002-11-21 at 17:04, Jeni Tennison wrote:
> Hi Eric,
> 
> > Now, even if that's not much fun, shouldn't we start by defining the
> > problem we are trying to solve :-) ?
> 
> 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.

> I think that the problem we should try to solve is to at least show
> that a radically alternative design is possible.
> 
> 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?

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.

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.

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.

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.

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.

Eric
 
> Cheers,
> 
> Jeni
> 
> ---
> Jeni Tennison
> http://www.jenitennison.com/
> 
> _______________________________________________
> Xpath-ng mailing list
> Xpath-ng at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/xpath-ng
> 
> 
-- 
See you in Baltimore.
                                    http://www.xmlconference.org/xmlusa/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------