search

ebu / ebu-tt-m-xsd

1 stars 0 forks source link

Some metadata elements only allowed on certain (tt:metadata) parents #13

Open spoeschel opened 5 years ago

spoeschel commented 5 years ago

[partly affects the Part 1 XSD]

The ttm:copyright element is only allowed on tt:head instead of also on any tt:metadata element.

The ebuttm:facet element is only allowed on certain parents of its tt:metadata parent (e.g. here). This also applies to ebuttm:authoringTechnique and ebuttm:binaryData.

The ebuttm:font element is only allowed on tt:styling/tt:metadata instead of also on any other tt:metadata element.

However the respective specs do not restrict this (if applicable, only the significance is restricted).

nigelmegitt commented 5 years ago

ttm:copyright

This schema defines the ttm:copyright element but says nothing about where it can be used, which matches what Tech3390 says, so it is correct.

The content models of both Tech3380 and Tech3390 specify that ttm:copyright is only permitted in <tt:head> and nowhere else.

I don't think there's any action to take here.

nigelmegitt commented 5 years ago

ebuttm:facet, ebuttm:authoringTechnique, ebuttm:binaryData and ebuttm:font

I agree that there's nothing in the spec that restricts where these can be placed, so I'll open a pull request to change the schema.

nigelmegitt commented 5 years ago

Looking at making these changes, I see that there are many more restrictions on the placement of metadata elements than just those listed on this issue:

headMetadata_type can take ttm:title, ttm:desc, then either 1) a documentMetadata or 2) any selection of elements in ebu-tt-metadata.class, and then ttm:agent, ebuttm:binaryData and any elements from other namespaces.

bodyMetadata_type and pMetadata_type are defined the same and can take ttm:title, ttm:desc, authoringTechnique, transitionStyle, facet then any elements from other namespaces.

divMetadata_type can take ttm:title, ttm:desc, authoringTechnique, binaryData, transitionStyle, facet then any elements from other namespaces.

spanMetadata_type can take ttm:title, ttm:desc, facet then any elements from other namespaces.

stylingMetadata_type can take ttm:title, ttm:desc, font then any elements from other namespaces.

What this means is that the current definitions apply the strict rules as intended when we wrote the metadata elements into tech3350 v1.1 especially, but with the modification of allowing document level metadata elements to be children of /tt/head/metadata without needing to be in a documentMetadata wrapper, though that is a supported option.

I'm very reluctant to remove this feature of the current structure because I think it's what we should be recommending people do, and because the schema is not normative. On the other hand I think it is reasonable to make a version of the schema that does strictly reflect the spec on its own. I will look at restructuring the schema files so that there are standalone definitions of all the metadata elements in Tech3390 that can be applied anywhere, and making the existing file keep its restrictions but take its element definitions from the standalone element definitions.

Hopefully that will meet the needs of folk who want a "strict-to-the-intent" schema that even enforces the should requirements and a "strict-to-the-spec" schema that only enforces the shall requirements.

I will update the README to explain this too.

andreastai commented 5 years ago

Generally a schema reflect the normative "shall" constraints of a specifications. This was the driver and the design decisions for given EBU-TT and TTML schemas. Therefore I think we should continue using this strategy unless we have a decision on this by the publishing group.

nigelmegitt commented 5 years ago

@tairt did you get a chance to review pull request #26 where I make two versions available, a "strict to the spec" (relaxed) one and a "probably what you want" (stricter) one?