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

I guess one solution would be to qualify the item-name with another attribute "nameIsUriPrefix" which if "true" would be considered an item-name URI prefix for all descendants that do not have the attribute present themselves.

Are you just trying to save on length of the name string? Does that offer any functional advantage?

It's syntactic sugar.


From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Friday, 12 December 2014 20:44
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Cc: John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>>, Andreas Tai <tai@irt.de<mailto:tai@irt.de>>, public-tt <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: [TTML2] Current draft - ttm:item concept


On Fri, Dec 12, 2014 at 6:16 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Friday, 12 December 2014 14:06



On Fri, Dec 12, 2014 at 1:46 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
From: John Birch <John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv>> Date: Friday, 12 December 2014 09:36

Re: 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).
I think such a rationalisation would be extremely useful in promoting the new generic ttm:item based metadata concept. Future versions of TTML derived standards could then adopt a strategy of defining mappings of domain specific metadata using the generic scheme.

Would it be useful to consider some means of avoiding ‘name collision’ between different derived standards defining mappings at the TTML level? E.g. a repository / registry?

Classification scheme URI on an item parent, inherited by children?

I defined the value space for @name on ttm:item as follows.
14.3.1 <item-name>

A <item-name> expression is used to specify the name of a metadata item expressed with a ttm:item element.

Syntax Representation – <item-name>


<item-name>
  : <named-item>
  | xsd:token<http://www.w3.org/TR/xmlschema-2/#token>
  | xsd:anyURI<http://www.w3.org/TR/xmlschema-2/#anyURI>


If an item name expression takes the form of an xsd:anyURI<http://www.w3.org/TR/xmlschema-2/#anyURI>, then it must express an absolute URI.

All values of <item-name> that do not take the form of (1) an absolute URI or (2) a token that has the prefix x- are reserved for future standardization by the W3C.

It would be helpful to be able to separate the classification scheme URI from the term relating to a specific ttm:item.

As I previously said, I modeled ttm:item around HTML's meta element type, which is effectively a name value pair.

The name itself should be sufficient to identify the "classification scheme", or better put, "name defining authority and name" or a "namespace and local name".

Using syntactic differences, I divided the value space of names into:

(1) names defined by W3C TTML specifications, i.e., those that take the form of a token and do not start with "x-";
(2) names defined by private parties for experimental use, i.e., tokens that start with "x-";
(3) names that take the form of an absolute URI, thus representing an uncountable set of namespaces each controlled by the 'authority' portion of the URI value;

The third of these forms provides everything you need to specify a naming authority (classification scheme) and local name. So anything else would simply be syntactic sugar and not represent a functional improvement.


Is that just a usage change to the existing syntax, to define that an xsd:anyURI can be used on a ttm:item that contains other ttm:items to specify a classification scheme, and that the item-name of those descendants should be considered relative? Seems a bit woolly to me, and like it would block new classification schemes from being adopted part way down the tree.

I'm not sure what problem you are attempting to articulate. With the drafted text, one can have:

<ttm:item name="absoluteUri1">
  <ttm:item name="absoluteUri2">a string value</ttm:item>
  <ttm:item name="absoluteUri3">an integer value</ttm:item>
</ttm:item>

It doesn't really matter if absoluteUri{1,2,3} share the same authority or not.


I guess one solution would be to qualify the item-name with another attribute "nameIsUriPrefix" which if "true" would be considered an item-name URI prefix for all descendants that do not have the attribute present themselves.

Are you just trying to save on length of the name string? Does that offer any functional advantage?

I've assumed that a fully qualified term consists of a prefix plus a term identifier, and that the prefix would normally be the URI of the classification scheme.


E.g.

<ttm:item scheme="http://acme.org/classificationscheme" name="acme metadata">
<ttm:item name="fruit">banana</ttm:item> <!— inherits scheme from parent —>
<ttm:item name="vegetable">carrot</ttm:item>
</ttm:item>



Best regards,
John


John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700<tel:%2B44%201473%20831700> | Ext : 2208 | Direct Dial : +44 1473 834532<tel:%2B44%201473%20834532>
Mobile : +44 7919 558380<tel:%2B44%207919%20558380> | Fax : +44 1473 830078<tel:%2B44%201473%20830078>
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, Excel London 24-26 February 2015 Stand No. N19

P Before printing, think about the environment

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 11 December 2014 17:41
To: Andreas Tai
Cc: public-tt
Subject: Re: [TTML2] Current draft - ttm:item concept


On Thu, Dec 11, 2014 at 4:01 AM, Andreas Tai <tai@irt.de<mailto: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<tel:%2B49%2089%2032399-389> | Fax: +49 89 32399-200<tel:%2B49%2089%2032399-200>
http: www.irt.de<http://www.irt.de> | Email: tai@irt.de<mailto:tai@irt.de>
------------------------------------------------

registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
  ­­