search

ebu / ebu-tt-m-xsd

1 stars 0 forks source link

Datatype (re)definitions in Part M #25

Open spoeschel opened 5 years ago

spoeschel commented 5 years ago

Currently the Part 1 repo and the Part M repo share a common set of EBU-TT datatypes that are all defined in both repos. Extending this set however can/will lead to issues.

Therefore datatypes that are only used by Part 1 should not be (re)defined by Part M. All datatypes used by Part M should therefore be renamed to use the ebuttmdt prefix and the urn:ebu:tt:metadata-datatypes namespace URN. Consequently the file ebu-tt-datatypes.xsd should be renamed to ebu-tt-metadata-datatypes.xsd. Datatypes only used by Part 1 should be removed from this file.

nigelmegitt commented 5 years ago

@spoeschel are you able to provide a list of the affected data types?

spoeschel commented 5 years ago

Yes, the following data types are used in Part M:

Directly mentioned in Tech 3390:

ebuttdt:mediaTimingType
ebuttdt:noTimezoneDateType
ebuttdt:smpteTimingType
ebuttdt:fontFamilyType
ebuttdt:fontSizeType

Added in addition, for abstraction:

ebuttdt:fontStyleType
ebuttdt:fontWeightType
ebuttdt:authoringDelayType
ebuttdt:transitionStyleAttributeType

Indirectly refered to by one of the former mentioned types:

ebuttdt:timecountTimingType
ebuttdt:fullClockTimingType
ebuttdt:cellFontSizeType
ebuttdt:percentageFontSizeType
ebuttdt:pixelFontSizeType

In addition, merging the fixes to other issues in this repo may add further data types, e.g. #2 will add:

ebuttdt:startOfProgrammeTimingType
ebuttdt:clockTimingType
ebuttdt:limitedClockTimingType
ebuttdt:timecountTimingType

Edit: added ebuttdt:startOfProgrammeTimingType

nigelmegitt commented 5 years ago

@spoeschel I'm not sure I understand - the issue was to remove the definition of data types not used by attributes defined by Tech3390, but I can't work out from https://github.com/ebu/ebu-tt-m-xsd/issues/25#issuecomment-503586371 which types can be safely removed.

nigelmegitt commented 5 years ago

By the way, doing this will also mean that the common data types need to have duplicate definitions in the ebu-tt-xsd, ebu-tt-d-xsd and ebu-tt-3-xsd repos. Unless you want to propose that we create an ebu-ttdt-xsd repo and put them all in there, making the change suggested here will mean that there is an additional maintenance overhead on all of those repos. Just noting it!

I started going through and there are indeed quite a lot of types that are defined here but not used.

nigelmegitt commented 5 years ago

@spoeschel I think I've gone through and found all the types not directly used and removed them in #28 but we should really think about the impact before merging it!

andreastai commented 5 years ago

There seems a general issue. As far as I can see (after a quick scan) Part 3 does not define the urn:ebu:tt:datatypes namespace and how to use datatypes "borrowed" from Part 1. This seems to be me a specification issue we may need to clarify first.

nigelmegitt commented 5 years ago

@tairt Part 3 is Tech3370, and defines the EBU-TT Datatypes prefix and namespace in §3.1.1 Namespaces, at the top of page 38. Also §3.3 Datatypes makes clear that no new data types are defined in Part 3, and that some datatypes are referenced from Part 1 and Part M.

Did you mean Tech3390, the metadata spec? If so, I agree there's a spec issue, and noted this in https://github.com/ebu/ebu-tt-m-xsd/pull/15#issuecomment-503027790

andreastai commented 5 years ago

Yes, I meant EBU-TT Part M.

It is an interesting question how to best resolve it. I agree that for the meantime the best approach is what @nigelmegitt and @spoeschel discussed (see this issue and the related discussions in othe issues).

In the longterm we may find a better solution. If we agree that Part 1, 3 and -D always import Part M then we may want to have just one Datatype schema document in the Part M repo.

spoeschel commented 5 years ago

@nigelmegitt Changes on common data types will indeed require work to be done in separate repos, but I think this is feasible to do so for now, in order to prevent the issues.

andreastai commented 5 years ago

I re-open this issue at the current solution leads to compatibility problems as described in https://github.com/ebu/ebu-tt-m-xsd/issues/30. Another of the discussed solutions (e.g. have duplicate datatypes but in a different namespace or have just one datatype definition) could solve the issues.