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

[David Rosenborg]

Hi Jeni,

> 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 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'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?

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

Cheers,
David