Consider restricting the metadata vocabulary that is permitted in DAPT

[cconcolato]

The current spec (silently) allows title, copyright and item (and maybe others). They are not needed or used at the moment. We should restrict the profile to not permit them to simplify implementations and maybe in a future version allow them when needed.

[andreastai]

I am not sure if this would reduce the complexity of an implementation. Implementations need already deal with foreign namespace vocabulary. In general, I think it is good practice to not fail if an implementation encounters unknown vocabulary but just ignore it.

[nigelmegitt]

Adding further restrictions to metadata is not exciting me - I'm not sure it's actually a good idea!

I definitely would keep title and copyright as being important in general use. item is less clear, but it provides a neat way for people to add their own proprietary metadata, as an alternative to defining their own XSD extensions, say.

[nigelmegitt]

Marked as agenda so that we can discuss and decide if we want to make any change.

[cconcolato]

Implementations need already deal with foreign namespace vocabulary.

The vocabulary I mentioned is in the TTML namespace.

In general, I think it is good practice to not fail if an implementation encounters unknown vocabulary but just ignore it.

I agree and we should probably mention that in the spec. This is also related to #110.

[css-meeting-bot]

The Timed Text Working Group just discussed Consider restricting the metadata vocabulary that is permitted in DAPT w3c/dapt#176, and agreed to the following:

• SUMMARY: Clarify specification to address points discussed above.

The full IRC log of that discussion

<nigel> Subtopic: Consider restricting the metadata vocabulary that is permitted in DAPT #176
<nigel> github: https://github.com//issues/176
<cpn> Cyril: I think the jist of my comment is, for everything we have in the spec will require work, conformance, implementation, testing
<cpn> ... So I'm inclined to make the required features as small as possible
<cpn> ... Agree that title and copyright don't hurt, people will know what to do with them
<cpn> ... Could settle to have guidance for implementers on what to do with them
<cpn> ... Don't know if we have other elements that could be present and should be ignored?
<cpn> Nigel: Item, title, and copyright are the elements we don't have yet
<cpn> ... ttm:role? Do we use that?
<cpn> Cyril: We did initially, but I don't think so now
<cpn> Nigel: Item is possibly the most complicated
<cpn> Cyril: It's related to extensibility. I think we should say more than we do now. We could say other metadata vocabulary from TTML2 may be present but may be ignored
<cpn> Nigel: We already say it. In 5.2 we talk about foreign elements
<cpn> ... There's an editor's note about presentation processors
<cpn> Cyril: It doesn't say for an element and attributes
<cpn> Nigel: In 5.2.1, says additional vocabulary may be included. So we've already permitted it but without saying about potential use of it
<cpn> ... I agree we could rename 5.2 to make it clear it's not just foreign, any unspecified elements or attributes
<cpn> Cyril: I think we should give guidance on processing
<cpn> ... I don't want to have people digging into the TTML spec to fully understand what a transformation process or it
<cpn> s/process or it/processor is/
<cpn> Nigel: A few potential actions: One is to describe the purpose of title and copyright and say you can put them in (particularly copyright, not sure about title)
<cpn> ... Next is to rename section 5.2, so it relates to any unspecified elements or attributes
<cpn> ... Or reword sentences about transformation process to make it more obvious what's meant
<cpn> ... Wording for a presentation processor is it may ignore vocabulary it doesn't understand and where DAPT doesn't require support for it
<cpn> Cyril: We don't say anything about the dapt namespace? An existing processor could see new vocabulary. We want deterministic behaviour for the future
<cpn> ... We have language about namespaces being extensible or reserved for future standardisation
<cpn> ... Want to say that implementations should ignore elements or attributes they don't recognise
<cpn> Nigel: We have in 5.2 about preserving whenever possible
<cpn> Cyril: Does it cover daptm namespace also?
<cpn> Nigel: We could change the name of 5.2 to unrecognised elements or attributes
<cpn> Cyril: I agree, but make it clear it's also about daptm, foreign namespaces, and add a note about it being an extensiblity point
<cpn> Nigel: Are there are other use cases for extensibility we want to cover?
<cpn> Cyril: We should think about elements, attributes, attribute values, text content (character data in general)
<cpn> Nigel: Anyone else with experience with this kind of extensibility to share?
<cpn> (nothing)
<cpn> Nigel: We would want existing implementations not to break on documents that include vocabulary not yet define
<cpn> ... And future implementations still be able to deal with v1 documents
<nigel> s/define/defined
<cpn> ... Ideally, but not sure the first of those is always possible
<cpn> ... Of those potential actions I listed, do we want to do all of them?
<cpn> Nigel: 1, specify title and copyright
<cpn> Cyril: Could be a note, doesn't have to be normative
<cpn> Nigel: So it's not part of the data model?
<cpn> Cyril: I wouldn't make it so as it's not directly related to processing of the content
<cpn> Nigel: Makes sense to add a note
<cpn> ... 2, rename section 5.2 to Unrecognised elements and attributes
<cpn> ... 3, change the editor's note to say presentation processors may ignore where DAPT doesn't require support for it
<cpn> ... 4, be explicit about the set of namespaces and that this is an extensibility point
<cpn> Cyril: I think that's a good outcome for this issue
<cpn> Nigel: I agree. If we do that, we should resolve #110 at the same time
<cpn> Cyril: Do we need to say anything about attribute values?
<cpn> ... As an example, if we want to add a value to an attribute and we don't have a registry
<cpn> Nigel: Registries aren't allowed to have normative semantics
<cpn> Cyril: Example, a new script-type value. How to deal with it in an implementation, as it's the value that would be unrecognised
<cpn> ... IME, a way you'd do it is to pick the closest existing value
<cpn> ... Don't want to close the extensibility issue now, we need to think about unrecognised attribute values more
<cpn> Nigel: Anything else to say on this?
<cpn> Cyril: No
<nigel> SUMMARY: Clarify specification to address points discussed above.