search

gs1 / EPCIS

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

SC8 - Any extended field shall be a URI or CURIE on an EPCISDocument or EPCISQueryDocument #384

Closed jmcanterafonseca-iota closed 2 years ago

jmcanterafonseca-iota commented 2 years ago

@mgh128

pending doubts:

  1. are schemaVersion and creationDate required on an EPCISQueryDocument?

  2. are extended fields allowed on epcisHeader or epcisBody ? and in resultsBody or queryResults?

jmcanterafonseca-iota commented 2 years ago

@mgh128 are schemaVersion and creationDate mandatory on an EPCISQueryDocument? which other fields admit extension on an EPCISDocument / EPCISQueryDocument? epcisHeader, epcisBody, resultsBody etc. ?

mgh128 commented 2 years ago

@mgh128 are schemaVersion and creationDate mandatory on an EPCISQueryDocument? which other fields admit extension on an EPCISDocument / EPCISQueryDocument? epcisHeader, epcisBody, resultsBody etc. ?

I think validation of schemaVersion and creationDate should be consistent for both EPCISQueryDocument and EPCISDocument since both can be used for transmission of event data, the former for the response from a query, the latter as input to a capture interface. Both are required within EPCISDocument so I think both should be required within EPCISQueryDocument - but let's check with the group today.

Regarding which other fields support extension in an EPCISDocument or EPCISQueryDocument, I don't recall us specifying epcisHeader, epcisBody or resultsBody as closed shapes in JSON Schema, although resultsBody is required to contain an eventList array of events of (any of the defined event types or an extended EPCISevent) and may contain a vocabularyList, which is validated. I think it has been a deliberate choice to keep the JSON / JSON-LD validation approach as 'open shape' as possible, to support future extensibility of the standard without requiring the clunky nested standard wrappers we saw in XML/XSD.

Looking at the EPCIS v1.2 XSD, ##other (vendor-defined, user-defined, sector-defined) other namespace extensions are supported within EPCISDocumentType, EPCISHeaderType, EPCISBodyType, VocabularyType, VocabularyElementType, EventList, EventListType (i.e. type of event appearing within eventList) as well as within ReadPointType, BusinessLocationType, ErrorDeclarationType - so I don't think that the validation for JSON/JSON-LD should be more restrictive than the XSD with respect to 'other namespace' extensions.

jmcanterafonseca-iota commented 2 years ago

with this patch I am following the recommendations from @mgh128 above However, We now have https://github.com/gs1/EPCIS/blob/master/JSON/Example_9.6.1-ObjectEvent-with-pseudo-SBDH-headers.jsonld in error.

@mgh128 please could you tell me what would be the appropriate CURIE to be used for the extended terms in that document i.e. sender, etc. ?

mgh128 commented 2 years ago

with this patch I am following the recommendations from @mgh128 above However, We now have https://github.com/gs1/EPCIS/blob/master/JSON/Example_9.6.1-ObjectEvent-with-pseudo-SBDH-headers.jsonld in error.

@mgh128 please could you tell me what would be the appropriate CURIE to be used for the extended terms in that document i.e. sender, etc. ?

I am wondering whether we will need to formally add those pseudo-SBDH replacement fields (sender, receiver, instanceIdentifier) as optional standard fields within the EPCIS ontology, appearing an EPCISDocument. In that case, they would map to epcis:sender, epcis:receiver, epcis:instanceIdentifier since I'm not aware of SBDH Web URIs we could map to.