Re: [json] JSON Query discussion group
Tatu Saloranta
One quick question: I was wondering about naming of the effort.
To me, "Path" and "Query" imply somewhat different (but overlapping)
feature sets:
* Path leaning towards traversal and selection of nodes, similar to
XPath, JsonPath
* Query seems more oriented towards aggregate operations (SQL, XQuery, Jaql)
Others may have different connotations with these terms.
But given the description of goals, it seems to me that the effort
would be more geared for defining a Path language, and not Query
language.
Am I totally off here? I just wonder if naming might lead people to
read too much into the effort; even if actual goals are clearly
listed.
-+ Tatu +-
Kris Zyp
I agree that there should be a distinction. However, I hadn't considered
them orthogonal and the line may be a little blurry, at least to me. I
agree with your distinction, but it seems to me that a query language
can act as a superset of the expressibility of a path language,
leveraging some of the same syntax for referring to elements within
expressions. It seems to me that some of the goals listed would put this
effort into the query language realm like sorting, filtering (granted
JSONPath and XPath have filtering, but that stills seems queryish to
me), aggregation, distinct sets. If this still puts us in the realm of a
"path" language we could change the name of the group, I suppose, but if
feels like querying to me. Or perhaps there should be separate efforts
on the evolution of each of these concepts.
Probably one of the key initial questions to consider as well, is
whether the goals that were listed represent a good direction for a JSON
querying language. Are some of the goals not important and are there
other goals that are more important in what you see as future use cases
of a JSON querying language. Obviously I have pointed to embedding
queries in URI's as an important use case, but surely there are others
that I haven't considered.
A related question is to what extent we should be utilizing and
extending JSONPath. It seems like have some level of interoperability
with JSONPath is attractive. In my efforts to build upon JSONPath, I
have attempted to do so, straying where I felt JSONPath unnecessarily
failed to intersect with JavaScript semantics. And if JSONPath is a good
foundation, what parts of the JSONQuery syntax that I had developed for
Dojo and Persevere seem like good steps towards a interoperable query
language. We certainly don't need to use that if it is the wrong direction.
Thanks,
Kris
Tatu Saloranta
>
> Tatu Saloranta wrote:
>> Hi Kris! I think this is a good group to have. :)
>> Am I totally off here? I just wonder if naming might lead people to
>> read too much into the effort; even if actual goals are clearly
>> listed.
>>
> I agree that there should be a distinction. However, I hadn't considered
> them orthogonal and the line may be a little blurry, at least to me. I
> agree with your distinction, but it seems to me that a query language
> can act as a superset of the expressibility of a path language,
> leveraging some of the same syntax for referring to elements within
> expressions. It seems to me that some of the goals listed would put this
> effort into the query language realm like sorting, filtering (granted
Actually after reading your post & related resources, I think I spoke too soon.
Yes, feature set actually does look like that of a query language, not
just path language. Apologies for confusion. I was paying too much
attention to references to json-path.
> JSONPath and XPath have filtering, but that stills seems queryish to
> me), aggregation, distinct sets. If this still puts us in the realm of a
> "path" language we could change the name of the group, I suppose, but if
> feels like querying to me. Or perhaps there should be separate efforts
> on the evolution of each of these concepts.
I don't know if this is feasible, but if it is, it would be quite nice
to have a path expressions as a building block or subset. Little bit
like separation between xpath and xslt. For some purposes basic path
language would suffice -- I am specifically thinking of streaming
processing here (an area of specific interest for myself) -- whereas
for others, full query language makes most sense.
I think these can be discussed in same group definitely.
-+ Tatu +-