Xsd validations

[RalphTro]

Went through all EPCIS Events residing in our folder https://github.com/gs1/EPCIS/tree/master/XML and checked it against our current XSD (used tool: Altova XML Spy). Came across a couple of things which I adjusted accordingly.

[RalphTro]

Dear @CraigRe and @mgh128 , A couple of adjustments to a number od our sample EPCIS events which should be now all compliant to our current XSD. We should discuss the two minor suggestoins for improvements of the XSD:

<xsd:attribute name="exception" type="xsd:anyURI" use="required"/>
-->
<xsd:attribute name="exception" type="xsd:anyURI" use="optional"/>

and

 <xsd:element name="epcList" type="epcis:EPCListType"/>
-->
<xsd:element name="epcList" type="epcis:EPCListType" minOccurs="0"/>

in tomorrow's call.

Kind regards, @RalphTro

[mgh128]

Dear @CraigRe and @mgh128 , A couple of adjustments to a number od our sample EPCIS events which should be now all compliant to our current XSD. We should discuss the two minor suggestoins for improvements of the XSD:

<xsd:attribute name="exception" type="xsd:anyURI" use="required"/>
-->
<xsd:attribute name="exception" type="xsd:anyURI" use="optional"/>

and

 <xsd:element name="epcList" type="epcis:EPCListType"/>
-->
<xsd:element name="epcList" type="epcis:EPCListType" minOccurs="0"/>

in tomorrow's call.

Kind regards, @RalphTro

Yes, @RalphTro - I agree that exception and type within SensorReport should now both be optional, since we could have a sensor report that does not correspond to a specific measurement type (e.g. it reports a boolean value or string value to indicate something like 'door opened' / 'door closed') and we'll have many sensor reports that do not correspond to error conditions or alarm conditions. Regarding epcList under which situations do you consider it optional?

[RalphTro]

Hi @RalphTro - many thanks for checking these.

Regarding XML/AssociationEvent/AssociationEventExamples.xml you still need to change this:

xsi:schemaLocation="urn:epcglobal:epcis:xsd:2 S:\Projekte\5 Mitarbeiter\Tröger\Working Groups\EPCIS_CBV_2dot0\MessageTests_2022-03-16\EPCglobal-epcis-2_0.xsd"

to something like this:

xsi:schemaLocation="urn:epcglobal:epcis:xsd:2"

(because most people won't be able to access your S drive) ;-)

:-) Thanks, @mgh128 . Adjusted (i.e. removed) it.

[RalphTro]

Dear @CraigRe and @mgh128 , A couple of adjustments to a number od our sample EPCIS events which should be now all compliant to our current XSD. We should discuss the two minor suggestoins for improvements of the XSD:

<xsd:attribute name="exception" type="xsd:anyURI" use="required"/>
-->
<xsd:attribute name="exception" type="xsd:anyURI" use="optional"/>

and

 <xsd:element name="epcList" type="epcis:EPCListType"/>
-->
<xsd:element name="epcList" type="epcis:EPCListType" minOccurs="0"/>

in tomorrow's call. Kind regards, @RalphTro

Yes, @RalphTro - I agree that exception and type within SensorReport should now both be optional, since we could have a sensor report that does not correspond to a specific measurement type (e.g. it reports a boolean value or string value to indicate something like 'door opened' / 'door closed') and we'll have many sensor reports that do not correspond to error conditions or alarm conditions. Regarding epcList under which situations do you consider it optional?

@mgh128 : from my POV, epcList is optional e.g. when quantityList is non-empty or if the object of observation is a physical location (i.e. the readPoint)

[sboeckelmann]

<xsd:attribute name="exception" type="xsd:anyURI" use="optional"/> was already included in my PR https://github.com/gs1/EPCIS/pull/408

@RalphTro thank you for pointing to your comment. I have also applied required changes for <xsd:element name="epcList" type="epcis:EPCListType" minOccurs="0"/>