Re: [TTML2] Current draft - ttm:item concept

On Thu, Dec 11, 2014 at 4:01 AM, Andreas Tai <tai@irt.de> wrote:

> Hi Glenn,
>
> From my view the introduction of the “ttm:item element concept” needs more
> investigation. Currently I see problems a) with current validation
> mechanisms and b) a good change to encounter the same content in different
> parts of a TTML 2 document.
>
> a) The semantic identity of a ttm:item element is defined by the value of
> the name attribute instead of the element name (e.g. there is a ttm:item
> element defined with the attribute name set to "creationDate" instead of a
> new element creationDate). In this scenario it is not possible to validate
> with XML Schema 1.0 that the content of <ttm:item
> name"creationDate">[Content]</ttm:item> conforms to the XML Schema 1
> DataType "date". Although this is possible with XML Schema 1.1 I do not see
> this as a validation option. The use of XML Schema 1.1 is not very wide
> spread yet and I do not know of any free parser that fully (!) supports XML
> Schema 1.1.
>

AFAIC, this is a non-issue: firstly, we don't specify a standard schema
system, but support two RNC and XSD (early on, we had actually been
explicit in favoring RNC as the primary, and XSD as secondary, but this
distinction has fallen away); secondly, as you well know, there are
*many* constraints
in TTML itself and in its various profiles that are not schema validatable,
e.g., see the enumeration "Additional Semantic Tests" in the TTV
documentation [1]; thirdly, there are tools, like TTV [1], that has no
trouble verifying the adherence of additional constraints;

[1] https://github.com/skynav/ttv

To take a case in point, the syntax of the <length> [2] and
<timeExpression> [3] value expressions are not validatable by any schema
system I have used, partly because additional constraints apply depending
on context of use.

[2] http://www.w3.org/TR/2013/REC-ttml1-20130924/#style-value-length
[3]
http://www.w3.org/TR/2013/REC-ttml1-20130924/#timing-value-timeExpression


>
> b) One use case of ttm:item is to integrate metadata that is already
> defined in other specification (e.g. in EBU Tech 3350/EBU-TT Part 1). It
> seems easier to me just to leave the metadata in the namespace where there
> are defined and integrate them by reference. Otherwise there is a good
> change that you have in two place (e.g. an ebuttm:creationDate element and
> a ttm:item element where the name is set to “creationDate”).
>

That would create a reference circularity. In the case of defining named
metadata items, I have assumed that there is general utility in use of most
if not all of the items defined in EBU-TT, so have defined them in a manner
independently from EBU-TT, in some cases, generalizing the description.

If there is a very strong need to keep some EBU-TT metadata distinct from
the general purpose item, then we could define extra items prefixed with
'ebu', or you could use a URI in an EBU defined namespace to name the item,
e.g.,

<ttm:item name="urn:ebu:tt:metadata:documentCreationDate">...</ttm:item>


> In general I very much appreciated the clear definition of the metadata
> section in the TTML 2 draft and the use of very helpful code examples to
> illustrate the usage of TTML vocabulary! Thanks for that!
>

One of the highest order design priorities I have applied in TTML is
vocabulary minimization. The overhead of introducing new vocabulary, both
in terms of specification and implementation, is significantly higher for
specialized vocabulary compared to general purpose vocabulary.

If one element definition (ttm:item) can serve the purpose of representing
dozens or hundreds of specialized vocabulary, then that is a big win
overall. Furthermore, generalized vocabulary and syntax tends to support
extensibility better. For example, it will not require a modification to
TTML2 to introduce new named metadata items, since the size of this set is
uncountable (due to use of an extensible set of names), while the approach
you advocate would require just that when new metadata comes along.

So, given the above, I have to respectfully decline the proposal to define
item specific vocabulary. Note that we do have some existing, item specific
vocabulary, e.g., copyright, desc, title, which at this point, I view as
legacy vocabulary (we might even want to define counterpart named metadata
items so these could be alternatively expressed with ttm:item).


>
> Best regards,
>
> Andreas
>
> --
> ------------------------------------------------
> Andreas Tai
> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
> http: www.irt.de | Email: tai@irt.de
> ------------------------------------------------
>
> registration court&  managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
>
>