How are Object Members and Array Elements different from Nodes

[goessner]

Thinking about the discussion in #309 and the current definitions ...

Member:  A name/value pair in an object.  (Neither itself a value, nor a node.)

Name:  The name in a name/value pair constituting a member.  (Not itself a node.)

leads me to the question, why object members can't be nodes.

Consider a subtile modification of definitions:

Member: A name/value pair in an object.

Element: An index/value pair in an array.

Node: A pair of a value along with its nodename (member name or element index).

Root Node: The unique node with the name "$" whose value is the entire argument.

Location: The unique path from the root node to a single node, manifested as a normalized path. This is an alternative node representation, i.e, in nodelists.

This way confusing formulations like ... member (not itself a node) become obsolete. We also get a more simplified definition for children and anchestors equivalent to child nodes and anchestor nodes. It seems to be consistent to that tree definition.

Is there something I am overlooking?

[cabo]

We could do this, but that would mean our data model no longer maps to JSON, which doesn't have free-floating members (or elements in the above definition). Also, from a practical point of view, one usually wants to look at a node in the sense we currently have it, not as a combination of the edge leading into it and the vertex itself (in graph theory, node also is usually a synonym to a vertex, not that combination).

(I think we already got rid of the confusing wordings.)

[glyn]

Thinking about the discussion in #309 and the current definitions ...

Member:  A name/value pair in an object.  (Neither itself a value, nor a node.)

Name:  The name in a name/value pair constituting a member.  (Not itself a node.)

leads me to the question, why object members can't be nodes.

Consider a subtile modification of definitions:

Member: A name/value pair in an object.

Element: An index/value pair in an array.

Node: A pair of a value along with its nodename (member name or element index).

That definition of node would not uniquely identify a value in the JSON tree.

For instance, in the JSON:

[1, [1]]

the above definition of node says there are two nodes with the value 1 and the nodename 0.

Root Node: The unique node with the name "$" whose value is the entire argument.

This isn't a node, according to the above definition, because it does not have a nodename.

Location: The unique path from the root node to a single node, manifested as a normalized path. This is an alternative node representation, i.e, in nodelists.

In the above JSON example, the Normalized Paths $[0] and $[1][0] both point at a single node (with value 1 and the nodename 0).

This way confusing formulations like ... member (not itself a node) become obsolete. We also get a more simplified definition for children and anchestors equivalent to child nodes and anchestor nodes. It seems to be consistent to that tree definition.

Is there something I am overlooking?

Also, following on from @cabo comment, the whole point of JSONPath is to select/extract JSON values from a JSON value, so that rules out selecting/extracting object members, since these are not JSON values.

[goessner]

I am not quite convinced yet.

Consider a subtile modification of definitions: Member: A name/value pair in an object. Element: An index/value pair in an array. Node: A pair of a value along with its nodename (member name or element index).

That definition of node would not uniquely identify a value in the JSON tree.

For instance, in the JSON:

[1, [1]]

the above definition of node says there are two nodes with the value 1 and the nodename 0.

Hmm ... where is it specified, that a node definition must be unique. Nodes in an XML DOM tree aren't either.

Root Node: The unique node with the name "$" whose value is the entire argument.

This isn't a node, according to the above definition, because it does not have a nodename.

Object members have an explicit nodename. Array elements and the root node have implicit node names (index and '$').

With our current definition members/elements and nodes are seemingly total unrelated.

Also, following on from @cabo comment, the whole point of JSONPath is to select/extract JSON values from a JSON value, so that rules out selecting/extracting object members, since these are not JSON values.

So maybe we can get completely rid of the term 'node' with its abstract definition then.

[cabo]

Also, following on from @cabo comment, the whole point of JSONPath is to select/extract JSON values from a JSON value, so that rules out selecting/extracting object members, since these are not JSON values.

So maybe we can get completely rid of the term 'node' with its abstract definition then.

That was a somewhat simplified statement. We do have a use for normalized paths, which identify nodes.

[glyn]

I am not quite convinced yet.

Consider a subtile modification of definitions: Member: A name/value pair in an object. Element: An index/value pair in an array. Node: A pair of a value along with its nodename (member name or element index).

That definition of node would not uniquely identify a value in the JSON tree. For instance, in the JSON:

[1, [1]]

the above definition of node says there are two nodes with the value 1 and the nodename 0.

Hmm ... where is it specified, that a node definition must be unique. Nodes in an XML DOM tree aren't either.

The consequences of a node not being unique in a tree include:

• Outputting a nodelist from a query would not be so useful because it would be missing location information.
• Converting a nodelist into an array of Normalized Paths would be tricky as the nodelist wouldn't define the order of duplicate entries.
• A node could have multiple parents, so the tree would't be a tree any more, it would be a directed acyclic graph.

Root Node: The unique node with the name "$" whose value is the entire argument.

This isn't a node, according to the above definition, because it does not have a nodename.

Object members have an explicit nodename.

Not sure I follow. Object members are not values, do not have nodes, and so don't need a nodename.

Array elements and the root node have implicit node names (index and '$').

With our current definition members/elements and nodes are seemingly total unrelated.

I don't think that's true. Each member has a value with a node. Each element has a node.

Perhaps the new section ("JSON Values as Trees of Nodes") in PR #309 makes things clearer?

Also, following on from @cabo comment, the whole point of JSONPath is to select/extract JSON values from a JSON value, so that rules out selecting/extracting object members, since these are not JSON values.

So maybe we can get completely rid of the term 'node' with its abstract definition then.

I don't think that's possible without introducing a synonym for "node".

[cabo]

I think this should be clear now in the draft -- can we close this?

[cabo]

2023-01-10 Interim: Yes, we can close.