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

[Jeni Tennison]

Hi David,

> I think it's enough to say that we have values. Values have type.
> There are a couple of types defined in the core data model, e.g,
> lists, number, nodes, booleans and strings. I don't think we need
> the distinction atomic even (which would mean not-list). Nodes
> aren't that atomic either when you think about it.

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'm quite keen on making the definition of "nodes" fairly open
>> ended, since I want to be able to use XPath NG with LMNL structures
>> and to allow modules to create their own node kinds (e.g. for
>> schema components). I wonder if we also need a "foreign object"
>> value type?
>
> Hmm, sounds interesting, but pretty hard (not knowing much about
> LMNL though other than "overlaid" trees ...). Could you outline how
> you think nodes could be enhanced to ease LMNL processing without
> interfering too much with the classical concept of an XML node?

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.

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

>>> [Issue: Singleton lists, are they treated transparently as the
>>> value of their only item?]
>>
>> I have a feeling that we'll have problems having nested lists if a
>> value is equivalent, at the data model level, to a list with a
>> single item that is that value. If we only had flattened lists, as
>> in XPath 2.0, then I don't think this would be a problem.
>> 
>> Note that just because the data model made the distinction wouldn't
>> necessarily mean that functions/operations would make the distinction.
>> Converting a value to a string is one example; as I defined it in the
>> proposal, it wouldn't matter if you had 'foo' or ('foo') or
>> ((('foo'))), the string value would still be 'foo'.
>
> I agree, it should be defined per function how list flattening is
> performed.

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

Cheers,

Jeni

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