[Xpath-ng] Proposal for definition of values/lists

[David Rosenborg]

Hi Jeni,

> I worry that if we don't have terms for "not-list" and
> "not-list-and-not-node" then people will make up their own, even in
> module definitions, and we'll end up getting muddled. XPath 2.0 uses
> "item" for "not-list" (which makes sense there because XPath 2.0
> sequences can't be items) and "atomic value" for
> "not-list-and-not-node"

I think that using terms like item or atom (i.e not-list) is good for
notational purposes but I'm not sure they should have any
special status in the data model.

> I think that the main thing is to have some kind of built-in
> extensibility (e.g. 'annotations' on nodes) that enables a node to
> basically have any structure. Then it's up to the module to define the
> axes/functions etc. that give access to that structure.

OK

> As far as the basic structure of the node goes, I think that never
> saying that "a node can only have one X" is helpful. In LMNL's case,
> nodes need to be able to have more than one parent (I actually
> implemented XPath access onto LMNL using Jaxen -- giving nodes more
> than one parent (and more than one 'self') works just fine :).

Schizophrenia by inheritance :-)

> To gain consistency, we might want to define a couple of standard
> flattening algorithms and encourage functions/operators to pick one of
> those.

Yes, good idea

Cheers,
David