Make XPath optional/informative

[mmccool]

As mentioned in #231, it was suggested that we remove XPath. Let's discuss this and come to a consensus in this issue.

Some points so far:

1. Spec says XPath 3.1 which has a nicer syntax for arrays, etc. in JSON
2. There are a limited number of implementations of XPath 3.1 at present; note that LinkSmart supports only XPath 3.0 (go library; there is also a Java library (saxon), though). UNIBO uses Node.js, no XPath library is available.
3. If two different TDDs use the same library to implement XPath queries, can we consider these two different implementations? - confirm with PLH
4. The above means that probably XPath queries will be "at risk" since we only have one implementation right now, and two are needed even for optional features.

[mmccool]

My opinion is that we should keep it. Arguments:

1. Optional, so does not constrain implementations
2. Functionally equivalent to JSONPath, provides simple query mechanism (not as pretty a syntax as JSONPath)
3. Testing issue can be resolved by having one more implementation based on Java/saxon for instance.

[mmccool]

Discussion:

1. @k-toumura has experience using both XPath and SPARQL. See Create Basic Query entry point #231 (comment). During the Nov 22 mtg, we discussed whether dropping XPath, and leaving SPARQL (as the only normative query support) would be ok for the use cases tested. It seems so.
2. We do have two SPARQL implementations, so it is not at risk.
3. Likely that JSONPath will become standard and adopted by TDD implementations in practice; we just have to wait for Discovery 2.0 to make it official
4. Fact that SPARQL is relatively complex is perhaps not a big deal if it is hidden by query front ends, e.g. Node-RED discovery plugins. A "basic" keyword search UI (for example) clearly could be built on top of an internal SPARQL query.
5. We could provide a bunch of examples of how to express semantics of equivalent JSONPath/XPath queries in SPARQL - to reduce the learning curve for developers.

[mmccool]

Consensus:

1. Remove XPath (or make it informative, like JSONPath?)
2. Focus on SPARQL; it will be the only normative query mechanism.
3. Provide a number of examples of how to map common JSONPath (and XPath?) queries into SPARQL. Need to come up with some specific use cases, including at least the following:
   • filter TDs to those that only use HTTP
   • search for keywords in descriptions and titles
   • search for semantic types of things (e.g. look for "echonetAirConditioner")
   • search for specific affordances (that is, the semantic type of affordance)
     (e.g. search for "enable energy savings mode" on all things)

[mmccool]

More discussion:

• Practical point of view, in long run, everyone will want JSONPath
• If we insist on XPath now, in long run, people will need to implement both
• Also limited number of libraries for XPath, making implementation hard (and 3.1 libraries, which we need for a nice array syntax, are even harder to find).

Decision:

• Make a PR to make XPath 3.1 API optional/informative (only). This is a practical matter: not enough implementations available to make it normative. @farshidtz to do, and we will discuss in the next meeting
• To confirm, leaving SPARQL as optional. Consumers should be ready to do a full download and their own filtering if no query interface is supported.