[Xpath-ng] Thoughts on work products

[Uche Ogbuji]

I'm glad discussion has already started in earnest.  First of all I
wanted to post my thoughts about how we might work on community
specifications.

Mike Kay just raised concerns on XML-DEV about our using the term "XPath
NG", claiming it might cause confusion in the community.  I disagree.  I
think it's no more confusing than, say the names "EXSLT" or "JDOM", but
we certainly should have an umbrella name for the specifications we work
on (distinct from the name of this mailing list).  I plump for "XPath
NG", but we could also come up with something cute such as "NextPath". 
I'm sure "XPath++" would also fall afould of Mike's objections.

As to what we produce, I think we should take a leaf out of the EXSLT
playbook.  I think we should produce relatively self-contained modules,
each of which exhibits healthy coupling and cohesion.  Each module would
address one particular aspect of extension/modification of XPath 1.0. 
One could also layer and combine modules.  As an exampele, there might
be an axis extension module which allows one to define extension axes,
say by using qnames or setting up a community registry.  On top of this
we might build an annotations module, which provides an extensible
system of annotations or properties for each node and uses the extension
axis module to define an annotations axis.  Then we might build a data
typing module which assigns data types to nodes using the constructs in
the annotations module.

The advantage of this, is that implementors and uers can pick and choose
what works best for them, and an overall improvement in clarity.

One disadvantage is interoperability.  If all different processors pick
different modules, the result would be somewhat short of chaos for
users.  That is why, after some modules have started to mature and we
have some decent implementation experience we could come up with
profiles, which are sort of super-modules which contain a simple list of
modules an implementation must implement under the profile.  So, for
example, we might define an "XPath NG Basic Profile", which includes a
set of the most common and readily implementable modules, etc.

Another disadvantage is that it might be a bit tough to word each module
so that it is self-contained, and still interacts cleanly with other
modules when implemented in tandem.  I think this is just a matter of
finesse and many eyes.

Thoughts?


-- 
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/py.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/index.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/index.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/developerworks/xml/library/x-tipgenr.html