Closed goessner closed 1 year ago
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.)
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.
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.
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.
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:
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".
I think this should be clear now in the draft -- can we close this?
2023-01-10 Interim: Yes, we can close.
Thinking about the discussion in #309 and the current definitions ...
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?