search

SMPTE / st429-14

Other
0 stars 0 forks source link

Invalid XSD #2

Closed smpte-bot closed 1 year ago

smpte-bot commented 6 years ago

Reporter: pal When: Tue, 9 May 2017 12:05:21 -0700 JIRA issue :https://standards.atlassian.net/browse/ST429P14-1

<DataEssenceCoding> should be mandatory since (a) it is mandatory in the underlying Track File and (b) it otherwise breaks the schema because of xs:any##other (other includes "cpl" in the "axd" context).

dcbullock commented 5 years ago

Maybe some text didn't come over as expected from Jira. Here is my note:

DataEssenceCoding optional element followed by xs:anyURI

sgcossette commented 5 years ago

Previous editor here. I don't understand the problem. The DataEssenceCoding element was made optional to prevent schema checking errors. Applications can make it mandatory. The type is xs:AnyURI, which I believe is correct. The next line in the schema is the xs:any to allow extension and is no different in construction that the cpl:AssetList type (optional elements followed by xs:any).

palemieux commented 5 years ago

In summary an optional element cannot precede <xs:any>.

See discussion at https://www.xml.com/articles/2018/06/13/upa-xml-schema/

The exact error is:

cos-nonambig: "http://www.smpte-ra.org/schemas/429-7/2006/CPL":EntryPoint and WC[##other:"http://www.smpte-ra.org/schemas/429-14/YYYY/Aux-Data"] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.

URL: http://www.w3.org/TR/xmlschema-1/#cos-nonambig

Making DataEssenceCoding mandatory resolves this issue, and is not limiting since DataEssenceCoding is mandated by the prose.

Applications can make it mandatory.

The schema is normative in the spec, so, in fact, no, the application cannot make it mandatory :)

sgcossette commented 5 years ago

In summary an optional element cannot precede .

Then ST 429-7 has this issue as well.

I am not opposed to making it required in the schema, which seems like the way to go. Not sure whether this will cause a problem with existing content, but perhaps it should be asked?

palemieux commented 5 years ago

Then ST 429-7 has this issue as well.

Why? TrackFileAssetType does not have <xs:any> .

Not sure whether this will cause a problem with existing content, but perhaps it should be asked?

I suspect that everyone that bothers with XSD validation made the element mandatory (or removed xs:any.

sgcossette commented 5 years ago

From above: ...is no different in construction that the cpl:AssetList type (optional elements followed by xs:any)

palemieux commented 5 years ago

...is no different in construction that the cpl:AssetList type (optional elements followed by xs:any)

cpl:AssetList is an element definition, not a type definition.

jpviollet commented 1 year ago

Thank you for the proposed revised draft ST 429-14.

It feels indeed appropriate to make the DataEssenceCoding XML element "required" in Schema - and in-line with how ST 429-18 (another type of AuxData spec) was written.

We should remove “[optional]” from the prose too (in section 10.4 title) - as the DataEssenceCoding “required” in section 9 is only the MXF Descriptor property, not the CPL Extension element. Thank you.