[Xpath-ng] Thoughts on work products

[Jeni Tennison]

Hi Uche,

I'm glad that you've set up this mailing list, and that you've posted
this overview of how you see things progressing. I think that sorting
out our goals is very important.

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

"FIXPath" (no particular expansion, or maybe Functional, Intuitive
XPath ;)

"PaX" (Paths for XML)

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

I think that modularity is absolutely key to XPath NG. But I think
that to support that modularity we need a good core on which we can
build -- we need to specify what makes up the core data model and
syntax and how this data model and syntax can be built on within the
modules.

For example, I started writing a kind of spec a while ago that said,
of values:

  Every value in XPath NG is a sequence containing zero or more items.

  The items in a sequence can be of three kinds: nodes, values and
  other sequences. Nodes are items that have identity whereas values
  are items that do not have identity.

  There are three core types of values in XPath NG: strings, numbers
  and booleans. These values can be cast to each other using the XPath
  1.0 rules. The only difference is that in XPath NG, strings that
  hold numbers in scientific notation can be cast to numbers, 'INF' is
  converted to Infinity and '-INF' is converted to negative Infinity.

  Sequences are cast to strings and numbers by converting the first
  item of the sequence to a string or number; if the sequence is empty
  you get an empty string or NaN. Sequences are cast to boolean true
  if they contain any items, boolean false if they do not.

  Other modules may add more data types, but every data type must
  define a mapping onto a string, a number and a boolean value, and
  how that data type is created from a sequence.

This is basically the same as XPath 1.0 except that it allows
sequences of normal values and that it specifically indicates what
kinds of additional data types are allowed and what a module must do
to specify them.

(I'm not proposing that this is how we define values, just trying to
illustrate the principal of defining a core that we can then build
on.)


I think we probably all have modules that we're particular interested
in pursuing. I'm interested in looking at supporting schema
information and in supporting access to LMNL structures, for example.
It looks like David Rosenborg is interested in the functional
programming support and in making XPath a stand-alone language. I
think that having these divergent goals should really help us make the
core something that is flexible and extensible -- we can check as we
go along that the facilities we build into the core are sufficient to
support the modules that we want to build on top of it.

So my first priorities would be to focus on the core data model and
expression syntax on which the modules can be built.

Cheers,

Jeni

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