redundant <extension> tag for AssociationEvent

[dakbhavesh]

Dear @RalphTro and @mgh128 ,

While building XML <-> JSON converter we realized one weirdness in the structure of AssociationEvent. Wondering why we have to wrap AssociationEvent with two extension tags instead of one similar to TransformationEvent. Shouldn't we fix EPCIS 2.0 XSD and AssociationEvent examples or Is there a genuine reason to keep double extensions tag?

FYI: @sboeckelmann

[mgh128]

Dear @dakbhavesh

wrappers are the container for everything introduced in later versions of the standard that we did not previously anticipate. Yes, it's ugly when we have multiple nested wrappers. However, it's a consequence of the 'closed shape' validation approach of XSD in which everything must appear in a strictly defined sequence. The reason why we probably need to wrap an AssociationEvent within two wrappers is that we're trying to ensure that EPCIS 2.0 data can still validate within an EPCIS implementation that uses the v1.2 XSD validation schema. Some people might think that a major version update (v2.0) is an opportunity to clean up the clunkiness of the past, even if that breaks backwards compatibility. It seems that EPCIS/CBV 2.0 is a major version update in terms of adding extra features (for reporting business-relevant sensor data) and simpler data exchange mechanisms (JSON/JSON-LD, REST/OpenAPI interface) but that we're too afraid to introduce any breaking change with v1.2, so in that respect it's actually closer to being v1.3 than really v2.0.

[dakbhavesh]

Well, having a double extension tag is making it hard for forward-look-up XML parsers (e.g. Java XMLSteamReader) to identify what's inside . If we have a single extension tag then it's becoming straightforward to identify event type. If we keep a double extension tag then we are leaving a dirty technical debt in the repository as we have to work it around and it may impact performance as well a bit.

[mgh128]

@dakbhavesh I completely agree with you - it is ugly and cumbersome. The group needs to decide whether to try to clean up these messy aspects of our XML/XSD data binding in v2.0 or whether backwards compatibility with v1.2 XSD is more important. The group needs to pick one. It's not possible to have both.

[RalphTro]

Dear @dakbhavesh , though I also agree that this is cumbersome, it is how it is defined in the EPCIS standard (see section 9.1., which we also revised as part of our effort) and how we agreed to proceed many months ago. In addition, as we agreed to disregard feature request, I suggest to not add it to our list of discussion points before public community review, unless you see a very strong reason to do so?

[dakbhavesh]

Dear @mgh128 and @RalphTro - I agree that backward compatibility should be given high importance and I support it. We will check if there is any workaround that can avoid additional extensions. We can live with this for now and pick up the topic again after a public community review. Can be marked as DEFERRED.

[RalphTro]

Thanks, @dakbhavesh !

[CraigRe]

Deferred (to v 3.0 ?), due to consensus agreement to retain 2.0 backward compatibility to EPCIS/CBV 1.x.

[CraigRe]

2.0 release will be accompanied by XSLT (developed by @sboeckelmann ), to strip out/add extension wrappers for 1.2 implementations.

(This should alleviate the need for modified EPCIS 1.2 schema tho tolerate any EPCIS 2.0-compliant documents that omit the extension wrappers.)

The intent is to reduce the number of wrappers around successive (versioned) EPCIS standard extensions, to reduce clunkiness on the one hand while at the same time ensuring that the EPCIS Document is not rejected as a whole (due to failed schema validation).

See also issue 290 (SBDH relaxation) https://github.com/gs1/EPCIS/issues/290 and pull request 283 https://github.com/gs1/EPCIS/pull/283/commits

[VladimirAlexiev]

Thanks @dakbhavesh! That was not just clunky but plain ugly. (I imagine year 2050: EPCIS 30.1 has 31 "extension layers")

[mgh128]

Many thanks to @sboeckelmann for planning to develop and share the XSLT transformations to address this. Elizabeth and I are wondering whether this will be a single XSLT that handles v1.2 --> v2.0 as well as v2.0 --> v1.2 or a pair of XSLT transformations, in which one of the XSLT transformations provides the "inverse function" to the other.

We want an EPCIS 1.2 repository to be able to use the XSLT to transform then ingest EPCIS 2.0 data. (inserting wrappers for elements that require this in v1.2 but don't use these in v2.0) This could also support an EPCIS 2.0 client asking an EPCIS 1.2 repository for data in v2.0 format.

We want an EPCIS 2.0 repository to be able to use the XSLT to transform then ingest EPCIS 1.2 data. (stripping for elements that require this in v1.2 but don't use these in v2.0) This could also support an EPCIS 1.2 client asking an EPCIS 2.0 repository for data in v1.2 format.

[sboeckelmann]

Dear @mgh128, I will start working on the XSLT asap. My plan is to have things configurable as much as possible. It will surely support both directions ( 1.2 <--> 2.0 ) and implementors will be able to use it within a response or request filter, that will either upscale 1.2 to 2.0 without making any changes if schemaVersion="2.0" was defined or downscale from 2.0 to 1.2. Also I will consider that some might want to strip the new EPCIS 2.0 specific elements from the XML, while others maybe want to keep them. We already implemented a similar approach for clients that weren't able to adopt 1.2 quickly and converted 1.x to 1.2 and vice versa by having such a XSL transformation filter in place. That's why I offered to pick up this task. We will have to provide it anyway, and if this allows us to make EPCIS 2.0 look less clunky / ugly it's something I gladly provide to the whole community. We will also require some nice README documenting the functionality with some good examples, but I am sure that we will find a few group members who will assist me in documenting things nicely. :-)

[mgh128]

Dear @sboeckelmann

Thanks again. This will be really useful and much appreciated by the community. I'll be happy to help to review/improve the README documentation for it, including preparing diagrams etc. even if you just email me photos of sketches etc.

In my previous comment I was mostly relaying a 'wish list' Elizabeth had emailed me. She will be very glad to hear that you're planning something so practical and configurable.

[sboeckelmann]

Dear @mgh128 @CraigRe,

after looking at some more versioning related aspects I think it's a good idea to also adjust the namespace for EPCIS 2.0. I have changed it from urn:epcglobal:epcis:xsd:1 to urn:epcglobal:epcis:xsd:2 These changes were added to my latest PR https://github.com/gs1/EPCIS/pull/295 In case you're strongly voting against it, I will quickly revert these changes.

But in my opinion it's an important improvement:

• highlight that there were major changes and cleanup
• allow for having 1.2 and 2.0 support within the same XML runtime, because they are uniquely identified by different namespaces

[mgh128]

Dear @sboeckelmann

I agree with that suggestion to change the XML namespace in 2.0, since it is a major version change and structurally different (less clunky) than the previous version.

[sboeckelmann]

Hi @mgh128, @CraigRe, we made some progress in XSL transformation. It's not (yet) good enough for creating a PR - but in case you want to take a first at what will be available for tomorrow's presentation: https://github.com/sboeckelmann/EPCIS/tree/issues/286-xsl/XSL

We will continue to improve things and I am quite optimistic that we will be able to showcase transformation of existing 2.0 XML examples in the repository.

[CraigRe]

Addressed in https://github.com/gs1/EPCIS/pull/303