search

gs1 / EPCIS

Draft files being shared for EPCIS 2.0 development
Other
22 stars 7 forks source link

[Question] Why bizLocation in the JSON Schema isn't just a URI? #170

Closed jmcanterafonseca-iota closed 3 years ago

jmcanterafonseca-iota commented 3 years ago

There is an inner id field? Is that really necessary?

mgh128 commented 3 years ago

It's because bizLocation and readPoint permit user-defined extension fields already within the previous versions, so the 'id' inner field is the key whose value is the URI.

Yes, I know it's hideously clunky but we have a load of baggage inherited from the previous versions and the XML data binding. We've tried to remove some of the clunkiness in the JSON/ JSON-LD data binding.

jmcanterafonseca-iota commented 3 years ago

I can understand. Could it be just allow both options? just the URI or a structured value? It would make the resulting JSON more beautiful and on the other hand meet the requirement of legacy compatibility ...

On Fri, Feb 12, 2021 at 7:06 PM Mark Harrison notifications@github.com wrote:

It's because bizLocation and readPoint permit user-defined extension fields already within the previous versions, so the 'id' inner field is the key whose value is the URI.

Yes, I know it's hideously clunky but we have a load of baggage inherited from the previous versions and the XML data binding. We've tried to remove some of the clunkiness in the JSON/ JSON-LD data binding.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gs1/EPCIS/issues/170#issuecomment-778352843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQEZJLQ5RVL4V7HJHUFQ7U3S6VU2ZANCNFSM4XRCW4BA .

-- IOTA Foundation c/o Nextland Strassburgerstraße 55 10405 Berlin, Germany

Board of Directors: Dominik Schiener, Serguei Popov, Navin Ramachandran ID/Foundation No.: 3416/1234/2 (Foundation Register of Berlin)

mgh128 commented 3 years ago

The problem with permitting either URI or a structured value is that we then have two alternative JSON paths to the URI that expresses the bizLocation or readPoint value, depending on whether or not a user extension field was expressed.

That may make the query processing more complex, as well as any translation between XML and JSON/JSON-LD. Currently, it consistently finds the URI value at /bizLocation/id whether or not a user extension field was present.

jmcanterafonseca-iota commented 3 years ago

Following the JSON-LD syntax and semantics it is perfectly valid representations in which the bizLocation is either a URI pointing to another Resource or just an embedded resource i.e. 

{
   "bizLocation": "urn:epc:id:sgln:123456.789010.0"
}
{
   "bizLocation": {
     "id": "urn:epc:id:sgln:123456.789010.0",
     "type": "BizLocation",
     "site": "urn:epc:id:sgln:123456.789010",
     "sst": "201"
   }
}

thus the JSON Schema should reflect it and allow both. Probably a clarification on the spec / implementation guide would be needed for people working with XML Schema.

In general, I think it would be good to avoid the trap of being limited by legacy serializations. And such issue can be overcome just by showing equivalence and interoperability requirements between existent and new serializations.

mgh128 commented 3 years ago

Thanks for the suggestion. The "id" is something inherited from the XML serialisation because it supports user-defined / vendor-defined extensions within the value of bizLocation and readPoint.

It's not only a question of being trapped by legacy serialisations. It's also a question of having a consistent JSON Path for where to expect the SGLN URI whether or not additional user/vendor extensions are present.

I understand that specifying that bizLocation expects a URI would support the situation where its value is a class identified by that URI - but from the JSON-only perspective, this results in two distinct JSON Paths - /bizLocation vs /bizLocation/id That might not be acceptable to the majority of the group who want JSON but don't care so much yet about it being JSON-LD. We'll need to have some further discussion on this on tomorrow's call. Thanks for preparing the pull request for some updates to the protected JSON-LD context file for EPCIS - but some of those will depend on how the group discussion goes tomorrow, so I can't approve all of that pull request until after that discussion.

If we really wanted to avoid the trap of the limitations of legacy serialisations, we might have forked v1.2 into an XML-only v1.3 with support for sensor data extensions and persistentDisposition and made a completely fresh start major version update in v2.0 either being JSON/JSON-LD only or at least breaking backwards compatibility with v1.2 and eliminating the ridiculous number of nested wrappers in the XML and rethinking whether there was a better way to handle this, possibly with a more open validation model.
We didn't make that brave choice at the time, so here we are, in the glorious muddle of v2.0 while still trying to maintain full backward compatibility with v1.2.

VladimirAlexiev commented 3 years ago

I agree it's best to use only the second representation (json object with id field) for uniformity.