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

[Jeni Tennison]

Hi David,

>> Every value in XPath NG is a list or an atom. A list is a sequence
>> of zero or more values. Atoms are of two kinds: nodes and data.
>> Nodes are atoms that have identity whereas data are atoms that do
>> not have identity.
>
> What's the purpose of having two kinds of atoms? Yes, nodes have
> identity, other data types have not. But there are numerous things
> that differentiate value types, what makes the identity property so
> special?

I think it's the impact on how implementations can store the value but
I admit I'm fuzzy on it -- it's a distinction that I've picked up from
Mike Kay. As you say, we could just say that atoms are of four kinds:
strings, numbers, booleans and nodes, and then break down nodes
further, but it feels like nodes and strings, numbers and booleans are
different kinds of things and we should have a convenient label for
them. If you've got a different phraseology that you'd prefer, then
please go ahead and suggest it.

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?

>>   [Issue: Do we need any more built-in data types?]
> Isn't this part of the anticipated modularity? By built-in you
> mean some sort of "core" data model?

Yes. We need a "core" data model so that we can define operations etc.
in a unified way. In the proposal, this core data model included
strings, numbers and booleans. I was asking whether there were any
others that people feel should be added at this level.

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

Cheers,

Jeni

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