[Xpath-ng] Thoughts on work products

[Uche Ogbuji]

> 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.

But I didn't read that in the above.

I just saw a list of possible contexts for XPath use.  I don't imagine anyone 
will ever say, this is the *definitive* host language list for XPath NG.  But 
there is no doubt that we should keep XQuery and XSLT 2.0 in mind as we work.  
We may not be able to accommodate the needs of these languages, but they are 
there, nevertheless, and we should at least explicitly state that we can't 
accommodate them, if so.


> Simplicity is subjective :-) ... do we want for instance something as
> simple as XPath 1.0 or more simple than XPath 1.0?

I think we can list simplicity as a goal without having to invoke a 
comparison.  After all, as you intimate, there is no way to measure such a 
comparison.  It is merely there as a general reminder as we work, and as a 
communication to others of our intentions.  I don't think either of these 
needs requires such a fine point.


> 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.

My thought about this was that in our own modules we would simply refer to 
relevant section numbers in the XPath 1.0 spec.  When finer granularity is 
required, we can always quote verbatim (I'm not sure whether there are any IP 
implications to this, given W3C copyrights).


> 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 this is a good goal.

Deasi Arpin's work on Sequential XPath is instructive here:

http://www.idealliance.org/papers/xml2001papers/tm/web/05-01-01/05-01-01.htm


> 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.

I agree that the core should not use Schema or any sort of PSVI.  These are 
the realm of modules.


> 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.

My leaning is also toward "try hard, but not too hard".  I fear that with some 
of the things we're already proposing, XPath 1.0 compat may be terribly to 
maintain.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html