Re: [ttml2] embedded content, background image styling, other edits

If EBU-TT does nothing to modify TTML semantics in a non-backward
compatible manner, then I would guess it is already a subset in the sense
that TTML ignores all elements and attributes in foreign namespaces.
However, I suspect you have something else in mind, i.e., semantic subset
(including new EBU semantics expressed by EBU vocabulary).

It is my goal to support the newly added semantics of EBU-TT vocabulary. So
you would require some transformation processing to express a full EBU-TT
document as a pure TTML2 document (syntactically and semantically).

On Tue, Nov 25, 2014 at 1:47 PM, John Birch <John.Birch@screensystems.tv>
wrote:

>  Thanks Glenn,
>
> I haven't had time to look at your email in detail but it would seem that
> this, and a possible schema substitution mechanism might go a long way
> towards allowing quite a high degree of alignment between EBU-TT and TTML
> 2.0. I would be delighted if it becomes possible to say that EBU-TT is a
> true subset of TTML, effectively re-named in a domain specific way :-)
>
> Best regards,
> John
>
>
>  *From*: Glenn Adams [mailto:glenn@skynav.com]
> *Sent*: Tuesday, November 25, 2014 08:43 PM
> *To*: John Birch
> *Cc*: TTWG <public-tt@w3.org>; Andreas Tai <tai@irt.de>; Nigel Megitt <
> nigel.megitt@bbc.co.uk>
> *Subject*: Re: [ttml2] embedded content, background image styling, other
> edits
>
>  I've added a new, generalized named metadata item mechanism, ttm:item
> [1] which I believe addresses your use case, and also can have many
> additional uses, such as representing other EBU and SMPTE metadata items.
>
>  [1]
> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#metadata-vocabulary-item
>
> On Tue, Nov 25, 2014 at 10:11 AM, Glenn Adams <glenn@skynav.com> wrote:
>
>> Thanks for your review and input.
>>
>> On Tue, Nov 25, 2014 at 2:43 AM, John Birch <John.Birch@screensystems.tv>
>> wrote:
>>
>>>  Hi Glenn,
>>>
>>>
>>>
>>> I’ve been looking at your proposal for embedded content (and I like it J
>>> but I noticed the following:
>>>
>>>
>>>
>>> ...
>>>
>>> <data type="text/plain; charset=us-ascii" length="44">
>>>
>>>   <chunk length="19">
>>>
>>>     VGhlIHF1aWNrIGJyb3duIGZveA==
>>>
>>>   </chunk>
>>>
>>>   <chunk length="25">
>>>
>>>     IGp1bXBzIG92ZXIgdGhlIGxhenkgZG9nLg==
>>>
>>>   </chunk>
>>>
>>> </data>
>>>
>>> ...
>>>
>>>
>>>
>>> I don’t see ‘charset’ as an attribute of data in the later definition…
>>>
>>
>>  In the above example, charset is a parameter of the MIME type
>> expression of the *type* attribute. No relationship with the 'encoding'
>> attribute.
>>
>>
>>>  I thought initially this was a typo and that it should be encoding,
>>> but then realised that ‘encoding’ is not permitted on the parent data
>>> element when using chunks?
>>>
>>
>>  Correct, 'encoding' is permitted only on the data element when the
>> content of the data element uses simple data embedding, i.e., consists only
>> of #PCDATA that encodes the data bytes. If a data element uses chunked data
>> embedding, i.e., uses chunk element children, then all of the encoded data
>> bytes are in child chunk elements, so the encoding attribute applies only
>> to the chunk children and not the data parent.
>>
>>  In the above example, the encoding attribute's default value 'base64'
>> applies on the chunk children, and is not relevant on the data parent.
>>
>>
>>
>>>   However, the binaryData element in EBU-TT includes an attribute that
>>> does not appear within your proposed scheme, which is the fileName
>>> attribute. This optional attribute may contain “A filename that may be used
>>> to identify the original filename of the tunnelled binary data”.
>>>
>>
>>  I'm not sure there is a useful use case for formalizing such a
>> name/identifier. It wouldn't have any relevant processing semantics in
>> TTML2, so it is definitely in the metadata category, which means using a
>> ttm:* attribute or a metadata element, e.g., one could use the following
>> convention with ttm:desc.
>>
>>  <data type='application/octet-stream'>
>>   <metadata>
>>     <ttm:desc>original_file_name=foo.bar</ttm:desc>
>>   </metadata>
>>   <chunk>
>>   ... encoded base64 data ...
>>   </chunk>
>> </data>
>>
>>  I wouldn't mind adding a new ttm:* element that generalizes the task of
>> defining metadata parameters, e.g.,
>>
>>  <ttm:parameter name='fileName'>foo.bar</ttm:parameter>
>>
>>  which would allow rewriting the above example to
>>
>>  <data type='application/octet-stream'>
>>   <metadata>
>>     <ttm:parameter name='original_file_name'>foo.bar</ttm:parameter>
>>   </metadata>
>>   <chunk>
>>   ... encoded base64 data ...
>>   </chunk>
>> </data>
>>
>>
>>>  *There is some discussion as to the usage of this element, it could be
>>> viewed as metadata of ‘historic interest’ (e.g. the name of the DOS file
>>> that is encapsulated by the binary data) or it could be seen as a directive
>>> (i.e. what to name a file should a processor re-create a file from the
>>> binary data). My personal leanings are towards the former use…*
>>>
>>>
>>>
>>> Regardless of the use of this attribute, I would like to propose that
>>> the TTWG consider adding a similar attribute to the data *and chunk*
>>> elements in TTWG. (*As an aside the chunk element you propose would be
>>> a better resolution to one of the original EBU-TT requirements where
>>> multiple floppy disk based DOS files make up an STL document.*) Clearly
>>> the name ‘fileName’ would be inappropriate in a more generic specification
>>> but I tentatively suggest the following (below).
>>>
>>
>>  We could consider it. But it definitely would not be appropriate on
>> chunk, which sole purpose is to enable streaming of data fragment children
>> of a data element. I guess you are thinking chunk might be used to contain
>> multiple original files (separately named) that are concatenated to form a
>> single data resource. This is counter to my intention that a chunk contain
>> a fragment of a data resource, or, if one wished, an entire data resource
>> (if a data element has a single chunk child like in the above example).
>>
>>
>>>
>>>
>>> Best regards,
>>>
>>> John
>>>
>>>
>>>
>>>
>>>
>>> <chunk
>>>
>>>   encoding
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-attribute-encoding>
>>> = (base16|base32|base32hex|base64|base64url) : base64
>>>
>>>   length = xsd:nonNegativeInteger
>>> <http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger>
>>>
>>>   xml:id
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-attribute-id>
>>> = ID
>>>
>>>   ident = xs:string
>>>
>>>   {*any attribute not in default or any TT namespace*}>
>>>
>>>   *Content:* #PCDATA
>>>
>>> </chunk>
>>>
>>>
>>>
>>> An ident attribute may be specified, and may contain an identifier for
>>> the contained data from an external context (e.g. the original filename).
>>>
>>>
>>>
>>> And
>>>
>>> <data
>>>
>>>   encoding
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-attribute-encoding>
>>> = (base16|base32|base32hex|base64|base64url) : *see prose below*
>>>
>>>   format
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-attribute-format>
>>> = <data-format>
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-value-data-format>
>>>
>>>   length = xsd:nonNegativeInteger
>>> <http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger>
>>>
>>>   src
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-attribute-src>
>>> = <data>
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-value-data>
>>>
>>>   type
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-attribute-type>
>>> = xsd:string <http://www.w3.org/TR/xmlschema-2/#string> : *see prose
>>> below*
>>>
>>>   xml:id
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-attribute-id>
>>> = ID
>>>
>>>   ident = xs:string
>>>
>>>   xml:lang
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-attribute-lang>
>>> = xsd:string <http://www.w3.org/TR/xmlschema-2/#string>
>>>
>>>   xml:space
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-attribute-space>
>>> = (*default*|*preserve*)
>>>
>>>   {*any attribute not in default or any TT namespace*}>
>>>
>>>   *Content:* #PCDATA | (Metadata.class
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#element-vocab-group-metadata>*,
>>> chunk
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-vocabulary-chunk>+)
>>> | (Metadata.class
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#element-vocab-group-metadata>*,
>>> source
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-vocabulary-source>
>>> +)
>>>
>>> </data>
>>>
>>>
>>>
>>> If simple data embedding is used, i.e., the content of the data element
>>> is one or more text nodes, then an ident attribute may be specified, and
>>> may contain an identifier for the contained data from an external context
>>> (e.g. the original filename). If chunked or sourced data embedding is used,
>>> i.e., the content of the data element contains any child chunk
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-vocabulary-chunk>
>>> or source
>>> <https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#embedded-content-vocabulary-source>
>>> element, then an ident attribute must not be specified.
>>>
>>>
>>>
>>>
>>>
>>>
>>> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>> John.Birch@screensystems.tv | 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*
>>>
>>>
>>> *John Birch | Strategic Partnerships Manager | Screen *Main Line : +44
>>> 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
>>> Mobile : +44 7919 558380 | Fax : +44 1473 830078
>>> John.Birch@screensystems.tv | 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:* 23 November 2014 22:50
>>> *To:* TTWG
>>> *Subject:* [ttml2] embedded content, background image styling, other
>>> edits
>>>
>>>
>>>
>>> I've updated the TTML2 ED [1] a few times in the last few days to:
>>>
>>>    - add embedded content element types (new section 9)
>>>
>>>
>>>     - audio
>>>       - chunk
>>>       - data
>>>       - font
>>>       - image
>>>       - resources
>>>       - source
>>>
>>>
>>>    - add background image styling
>>>
>>>
>>>     - tts:backgroundImage
>>>       - tts:backgroundRepeat
>>>       - tts:backgroundPosition
>>>
>>>
>>>    - sub-divide former parameters section into profiles section and
>>>    parameters section
>>>
>>>  For detailed diffs, see change sets [2][3][4][5][6].
>>>
>>>
>>>
>>> [1] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html
>>>
>>> [2] https://dvcs.w3.org/hg/ttml/rev/d16d284100b9
>>>
>>> [3] https://dvcs.w3.org/hg/ttml/rev/67327764d375
>>>
>>> [4] https://dvcs.w3.org/hg/ttml/rev/25035c814da5
>>>
>>> [5] https://dvcs.w3.org/hg/ttml/rev/cc2b7aad7e7a
>>>
>>> [6] https://dvcs.w3.org/hg/ttml/rev/e3fdbceb09cb
>>>
>>>
>>>
>>>  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
>>>    ­­
>>>
>>
>>
>
>  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
>    ­­
>