search

ebu / ebu-tt-m-xsd

1 stars 0 forks source link

ebuttm:transitionStyle definition/location #12

Open spoeschel opened 5 years ago

spoeschel commented 5 years ago

The ebuttm:transitionStyle element is defined as having xs:string content without any attributes in the XSD (e.g. here). However it shall be an empty element and have two mandatory attributes, according to Part M. Furthermore it shall not be restricted to only specific parents of its tt:metadata parent element.

[not to be mixed up with #7]

nigelmegitt commented 5 years ago

it shall not be restricted to only specific parents of its tt:metadata parent element.

Tech3390 says:

Should not be placed in /tt/head/metadata; use ebuttm:documentTransitionStyle in /tt/head/metadata to summarise the transition style(s) used within the document.

It's correct that it is not a "shall" restriction, only a "should" one, but an XSD cannot give a warning when a should constraint is broken: it can only give an error or no error. This schema is not normative as part of the definition of the specification, so my preference would be to continue to issue an error if the SHOULD constraint is broken.

Thoughts?

andreastai commented 5 years ago

Until now we use an XSD only to enforce "SHALL" constraints. If an document do not pass a Schema it is not valid. Not valid is in my interpretation that it does not conform to the specification.

spoeschel commented 5 years ago

Currently in some cases restrictions cannot be enforced completely as e.g. they cannot be covered by an regex or further conditions apply. So the XSD definitely leads to False Positives.

Handling SHOULDs like SHALLs would mean that we also had False Negatives. I would rather prefer to only have false results in one way - not in both ways. So one can still say (keeping in mind that the XSD is informative): If it doesn't pass the XSD, it cannot be a valid EBU-TT document.