orderBy clause can not locate parent of user extension field

[shalikasingh]

Hi @RalphTro, @mgh128,

According to EPCIS 2.0 draft, the orderBy clause is stated as below:

The value of this parameter SHALL be one of: eventTime , recordTime ,
or the fully qualified name of an extension field whose type is Int, Float,
Time, or String.

One concern regarding the above statement is if a client provides in orderBy a fully qualified name[FQN](i.e, user extension field), how the EPCIS query interface implementors will detect that the FQN provided lies within which level in an EPCIS event (i.e, user extension can be present at a various level like errorDeclaration, bizLocation, ilmd, etc). For meaningful sorting of events returned in eventList, we believe along with FQN client must also provide the nested path at which FQN is expected to be present. If we agree to the suggestion then oderBy clause in query-schema.json may look like below:

As_is:

"orderBy": {
      "type": "string"
    }

To_be:

 "orderBy": {
      "type": "object",
      "properties": {
        "field": {
          "type": "string"
        },
        "path": {
          "type": "string",
          "enum": [
            "Ilmd",
            "Inner_Ilmd",
            "BizLocation",
            "Inner_BizLocation",
            "ReadPoint",
            "Inner_ReadPoint",
            "ErrorDeclaration",
            "Inner_ErrorDeclaration",
            "SensorElementList",
            "Inner_SensorElementList",
            "SensorReport",
            "Inner_SensorElementList",
            "SensorMetadata",
            "Inner_SensorMetadata"
          ]
        }
      },
      "required": ["field"]
    }

[CraigRe]

@sboeckelmann / Vlado's suggestion for XPath/JSONPath-compatible approach, declaration of fieldname in JSON by means of /fieldname, unless the field appears in more than once place, in which case the entirepath/fieldname would need to be explicitly declared.

There appear to be no backward compatibility issues; queries used in 1.2 implementations will continue to function in 2.0.

Vlado: True XPath would require @ sign... Suggestion is -- instead of true XPath -- use "pseudo" XPath (does not use @ sign, does not use "extension" anywhere in the path... keeping it pure, without the XML specifics.

Suggestion of @dakbhavesh & @shalikasingh : "orderBy": { "type": "object", "properties": { "field": { "type": "string" }, "path": { "type": "string" // json-path or xpath } }, "required": ["field"] }

per @sboeckelmann : exmaple:Ilmd/someUserExtension/bestBeforeDate To do this with XPath for https://github.com/gs1/EPCIS/blob/master/REST%20Bindings/query-schema.json , we would also need to add this to the SOAP interface specification.

@jmcanterafonseca-iota : Interpretation of prefix in JSON-LD (if followed strictly) is more syntactic than semantic than syntactic; we need to look at this in terms of query alignment with XPath...

@RalphTro : we need to check:

1. Would a user extension need to be expressed as a URI ? (seems likely)
2. Would URI need to be percent-encoded (i.e., because of forward slashes) in the query string ?

Vlado: ilmd is a standard field and I think we need to prefix every custom field, so a better example imho is ilmd/ex:someUserExtension/ex:bestBeforeDate

[sboeckelmann]

After having discussed internally, we came to a conclusion that we will not need any structural changes on SOAP or JSON query structures specifically for orderBy. We can leave it upto implementers to provide exact location of extension field through their own expression as part of value of orderBy key. Value can be in terms of either json object path, XPATH, URI or custom expression.

I will send out an E-Mail to you with some more details @dakbhavesh, @shalikasingh and team kindly prepared for us.

[CraigRe]

Consensus re-affirmed that we are not going to change the format; @dakbhavesh: orderBy can accept any XPATH expression.