Re: Draft TTML Codecs Registry - Issue-305

Could you cite the exact documents/sections that you are referring to by
"quoted text"?

Regarding

The processing behaviour may or may not be expressed in terms of
> TTML1-style profile features. There's no other language other than prose
> available for this purpose (that I know of).


If a specification defines processing semantics that must be supported in
order for a processor to conform to the specification, and if that
specification does not define any feature/extension, then I would firstly
view that as a broken specification; however, another potential
interpretation is that the specification implies an otherwise unnamed
feature/extension whose feature/extension designation corresponds to the
profile designation. That is, the profile designation serves as a
high-level, un-subdivided designation of the set of semantics mandated by
compliance with the defined profile.

This might be a way out of this without having to have such specifications
define individual, fine-grained feature/extension designations.

Anyway, I'm still waiting for a someone to articulate a use case for
signaling a content profile, or any aspect of a content profile (e.g.,
namespaces, schemas).




On Thu, May 15, 2014 at 1:28 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  Since namespaces and schemas define and constrain document contents
> without defining processing behaviour the quoted text defines a content
> profile declaration. It isn't asking for anything concerning specific
> processor capabilities but is merely describing  the contents of the
> document. The information may be used for downstream processing by context
> aware processors. The reference to namespace-aware compression makes clear
> that the mapping from whatever label scheme we choose to namespaces and
> schemas is important.
>
>  However it's clear that we expect the receiving system to use the
> information to direct its processing, as described previously.
>
>  Consider that the specification of a TTML variant x consists of the
> union of a content profile Cx and a description of processing behaviour Bx,
> which I'll express as S = C + B. The content profile shall itself reference
> one or more namespaces and schema locations. The processing behaviour may
> or may not be expressed in terms of TTML1-style profile features. There's
> no other language other than prose available for this purpose (that I know
> of).
>
>  It is possible to define two specifications S1 and S2 where S1 = Cx + Bx
> and S2 = Cx + By, i.e. the same contents are processed with different
> behaviour. By the quoted text there is no need to differentiate between
> them from an ISO 14496 perspective. However we understand from our
> knowledge of the problem space that it may be useful to signal to a
> receiving system which behaviour set is desirable. And it may be helpful in
> a receiving system to differentiate between the available behaviours in
> order to provide the optimal experience.
>
>  Would it be contrary to the spirit of the ISO wording to assign short
> labels each corresponding to some Specification, and for receiving systems
> to be expected to dereference (using a cached lookup table!) from those
> labels to the namespaces and schema locations contained within that
> specification's content profile? This would satisfy the ISO requirements
> and permit us to signal additionally the processor features and behaviours.
> At this stage the expression of those is not our concern – just that there
> is a document somewhere that describes how the implementation should work.
>
>  Going back to the previous example, if a document conforms to Cx then it
> could be signalled either as S1 or S2 or both, and if the content provider
> has verified that presentation will be acceptable either way then both S1
> and S2 would be declared, otherwise just one of them (or neither if there's
> some other Sn that also uses Cx).
>
>  With this scheme combinatorial logic wouldn't really make sense – you
> could infer something about unions and intersections of content profiles
> but since the language used to describe processor behaviours can't be
> mandated (okay it could in theory, but it wouldn't be accepted in practice)
> it wouldn't be a well defined operation. Incidentally this is in no way a
> critique of the effort put in by Glenn, and its outcomes, in terms of
> defining content and processor profiles – though it might be nice to verify
> that this simple expression can be expanded into that scheme should a
> specification writer choose to do so.
>
>  This implies that every combination of content profiles and behaviours
> must be considered carefully and registered as a new specification with a
> new label. It also implies that if a document declares conformance with a
> set of specifications then it must conform to every member of the set of
> content profiles and it may be processed according to any one of the set of
> processing behaviours.
>
>  The expression of that set is as described previously, where we pick our
> favourite delimiter out of a hat made out of ampersands.
>
>  Also: this topic was discussed in summary briefly on the call today and
> a new suggestion arose, that some guidance for 'reasons why the TTWG would
> reject an application for registration' would be helpful. When requiring
> combinations to be registered separately there's a greater need to ensure
> that the registration process is quick and painless, and this guidance
> would help us and those who may follow to expedite it.
>
>  Nigel
>
>
>   On 15/05/2014 18:00, "Michael Dolan" <mdolan@newtbt.com> wrote:
>
>    I believe the problem statement is to replace the potentially unwieldy
> long strings in the namespace & schema_location fields defined in 14496-12
> and 14496-30 with a more compact string suitable for the DASH manifest
> codecs field.
>
>
>
> From 14496-12, AMD2:
>
>
>
> namespace is a null-terminated field consisting of a space-separated
> list, in UTF-8 characters, of
>
> one or more XML namespaces to which the sample documents conform. When
> used for metadata,
>
> this is needed for identifying its type, e.g. gBSD or AQoS [MPEG-21-7] and
> for decoding using XML
>
> aware encoding mechanisms such as BiM.
>
>
>
> schema_location is an optional null-terminated field consisting of a
> space-separated list, in UTF-
>
> 8 characters, of zero or more URL’s for XML schema(s) to which the sample
> document conforms. If
>
> there is one namespace and one schema, then this field shall be the URL of
> the one schema. If there
>
> is more than one namespace, then the syntax of this field shall adhere to
> that for xsi:schemaLocation
>
> attribute as defined by [XML]. When used for metadata, this is needed for
> decoding of the timed
>
> metadata by XML aware encoding mechanisms such as BiM.
>
>
>
> I’m warming up to the idea of requiring TTML content profiles be created
> for the combinations.
>
>
>
>                 Mike
>
>
>
> *From:* Glenn Adams [mailto:glenn@skynav.com <glenn@skynav.com>]
> *Sent:* Thursday, May 15, 2014 9:15 AM
> *To:* Nigel Megitt
> *Cc:* Michael Dolan; TTWG
> *Subject:* Re: Draft TTML Codecs Registry
>
>
>
> My understanding from Dave was that the problem is how to answer the
> following method:
>
>
>
> boolean canPlay(String contentTypeWithParameters)
>
>
>
> I have not seen any statement of a problem that relates to signaling
> content conformance.
>
>
>
> As for requirements driving the ability to express a combination of
> profiles, we already have (in TTML1) and will have more (in TTML2) that
> permits a user to characterize processing requirements by means of a
> combination of existing profiles. Consequently, any shorthand signaling of
> first-order processor support needs to be able to repeat the expression of
> such combinations.
>
>
>
> I don't buy any "its too complex" argument thus far, primarily because
> nobody has stated what is (overly) complex in sufficient detail to
> understand if there is a problem or not.
>
>
>
> My perception of the TTML profile mechanism is that it is easy to
> understand and implement, and, further, that it is a heck of lot easier to
> understand and implement than XML Schemas.
>
>
>
>
>
> On Thu, May 15, 2014 at 9:58 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
> Agreed there's a gulf of understanding/expectation that we need to bridge.
>
>
>
> Can anyone volunteer to draft a set of requirements for this
> functionality, in the first instance being the smallest set needed to meet
> the ISO specs? (Mike, I guess I'm thinking of you, following our discussion
> at the weekly meeting earlier)
>
>
>
>
>
> On 15/05/2014 16:48, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
>
>  i can see this subject is not going to be resolved easily as we clearly
> have a large gap about requirements; e.g., i think there are no
> requirements to signal content conformance, but only client processor
> requirements, i think we must use the TTML profile mechanism, etc
>
> On Thursday, May 15, 2014, Michael Dolan <mdolan@newtbt.com> wrote:
>
> Maybe "highly undesirable", but if we don't address the A + B signaling
> explicitly, then profiles need to be created for all the combinitorics of
> namespaces in practice. Not the end of the world, but virtually prevents
> the
> simple signaling of 3rd party namespaces already provided by the
> namespace/schemaLocation mechanism today. No I am not proposing we use that
> - I am pointing out a deficiency in this proposal that we already address
> today in 14496.
>
> Anyway, we need to go through the points in my email a week ago - if not
> today, then on the 29th.
>
>         Mike
>
> -----Original Message-----
> From: David Singer [mailto:singer@mac.com <singer@mac.com>]
> Sent: Thursday, May 15, 2014 5:20 AM
> To: Glenn Adams
> Cc: TTWG
> Subject: Re: Draft TTML Codecs Registry
>
> OK
>
> Though it will be a sub-parameter of the codecs parameter for the MP4 file
> type, from the point of view of TTML it's actually a profile short name
> registry rather than codecs registry, so I think we should rename it.
>
> the values here should be usable in both
> a) the profiles parameter for the TTML mime type
> b) the codecs parameter for the MP4 mime type
>
> so, also "named codecs" -> "named profiles"
>
>
>
> I agree with Cyril that we only need a single operator here (implement one
> of these profiles and you're good to go), both because we don't need the
> complexity, and because a "implement both/all of these" is effectively
> inviting file authors to make up new profiles ("to process this document
> you
> have to implement both A and B"), which is (IMHO) highly undesirable.
>
>
>
> On May 15, 2014, at 9:55 , Glenn Adams <glenn@skynav.com> wrote:
>
> > See [1].
> >
> > [1] https://www.w3.org/wiki/TTML/CodecsRegistry
>
> Dave Singer
>
> singer@mac.com
>
>
>
>
> ----------------------------
>
>
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>
>
>
>