- From: Michael Dolan <mdolan@newtbt.com>
- Date: Mon, 15 Jul 2013 08:48:37 -0700
- To: "'Timed Text Working Group'" <public-tt@w3.org>
- Message-ID: <00d901ce8172$c73b4c10$55b1e430$@newtbt.com>
Glenn-
The reason that I think a profile document itself is an inadequate tool to define a profile is that the granularity of the features has never (to date) matched the defined profile capabilities per the related prose for those profiles.
Without explicit restriction, a feature must be assumed to be fully supported.
For example, let’s use tts:color. SDP-US constrains the color representations in ways that are not covered in the TTML profile feature, #color. The granularity of this feature in TTML is all or nothing. Therefore, if an SDP-US (only) decoder were to receive a profile (URI or inline) that contained the #color feature, it would be forced to reject the instance document since the decoder does not support all the representations.
The extension mechanism cannot, at least as I read the spec, be applied to TTML features, only 3rd party features – that is, extensions to TTML, not TTML itself. And, 3rd parties are prohibited from defining new features in the TTML namespaces.
Since it is common practice today is to define profiles with features constrained in ways not pre-defined in TTML 1.0, how is it possible to create a useful profile document? Perhaps I am missing something about the profile/feature/extension mechanism?
But if we can’t make a useful profile document, there is little point in requiring the URI for it to be resolvable to a physical document.
Regards,
Mike
From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Monday, July 15, 2013 6:58 AM
To: Michael Dolan
Cc: Timed Text Working Group
Subject: Re: ISSUE-261: signaling docoument profile conformance is separate from decoder presentation requirements [TTML.next]
On Fri, Jul 12, 2013 at 2:40 PM, Michael Dolan <mdolan@newtbt.com> wrote:
Agreed. But the inline form is already permitted, and I don't see a
compelling reason to disallow it. That said, I would expect the "normal"
case is to use a URI.
Since you said "URI" and not URL, it begs that we return to the question of
resolvability and existence of the TTML syntax profile. I still maintain
that the profile must be definable in prose or other means without actually
creating and/or posting a resolvable profile document that conforms to the
feature syntax defined in TTML.
These are orthogonal issues:
(1) defining a profile
(2) defining a feasibly resolvable profile document
The feature granularity is insufficient to
describe any (I think) of the profiles in use today.
Note that the purpose of a feasibly resolvable profile document is not intended to formally define a profile (in the more general sense you are using it). It is up to us (or extension definers) to be as specific as desired in enumerating feature and extension designators.
A feasibly resolvable profile document is effectively needed (in the use of a non-standard profile and in the absence of an inline profile document) in order for a processor to know whether it should process a document based on which features are implemented by the processor.
Minimally there are
certainly profile examples that cannot be (sdp-us and cff-tt). The feature
mechanism cannot be extended by 3rd parties.
If by "extended by 3rd parties" you mean defining new non-standard "features", then yes it is supported, since a non-standard "feature" is just what we call an "extension". Or do you have something else in mind by "extended"?
This effectively forces
permitting the profiles to be defined by other means, and therefore, there
cannot necessarily be a profile document, and therefore cannot be resolvable
in all cases.
The definition of a profile document and its accessibility by a processor is not related to the definition of a profile itself. It (the document referenced by the URI) serves an operational purpose only.
I see no legitimate reason for anyone to define a TTML profile (as presently defined) and fail to define a feasibly resolvable profile document instance.
Regards,
Mike
-----Original Message-----
From: Pierre-Anthony Lemieux [mailto:pal@sandflow.com]
Sent: Friday, July 12, 2013 1:24 PM
To: Glenn Adams
Cc: Timed Text Working Group
Subject: Re: ISSUE-261: signaling docoument profile conformance is separate
from decoder presentation requirements [TTML.next]
> Is there a use case for having a document include inline the definition of
a content profile it claims to conform to?
Such a use case does not immediately come to (my) mind.
-- Pierre
On Fri, Jul 12, 2013 at 1:18 PM, Glenn Adams <glenn@skynav.com> wrote:
> Is there a use case for having a document include inline the
> definition of a content profile it claims to conform to? Or is it
> sufficient to allow a document to refer to a URI which is feasibly
> resolvable to a definition of a content profile?
>
>
> On Fri, Jul 12, 2013 at 2:08 PM, Pierre-Anthony Lemieux
> <pal@sandflow.com>
> wrote:
>>
>> > > Some means must be defined to separately signal these different
>> > > semantics.
>> > For example, we could create a new element and attribute -
>> > <ContentProfile> and contentProfile.
>>
>> Sounds good. I also see value in exploring means for (a) defining a
>> content profile and (b) signaling conformance of a document to one or
>> more content profile.
>>
>> > <ContentProfile>
>>
>> What about following the <ttp:profile> template with the following
tweaks:
>>
>> - adding a @designator attribute allowing the content profile
>> designator to be specified
>> - @use can contain one or more URIs, each identifying a content
>> profile to be included in its entirety by reference, thereby avoiding
>> having to repeat all features already defined in another profile.
>> Perhaps @use can reference "profile" even when defining
>> "contentProfile" so that existing content designator can be used.
>> - allowing constraints over a base content profile to be specified
>> using value="prohibited"
>>
>> <contentprofile designator="http://example.noname/profile1"
>> use="http://example.noname/profile4 http://example.noname/profile3"
>> xmlns="http://www.w3.org/ns/ttml#parameter">
>> <features xml:base="http://www.w3.org/ns/ttml/feature/">
>> <feature value="prohibited">#fontStyle-italic</feature>
>> <feature value="use">#fontStyle-bold</feature>
>> </features>
>> <extensions xml:base="http://example.noname/profile1">
>> <ttp:extension
>> value="required">#prefilter-by-language</ttp:extension>
>> </ttp:extensions>
>> </contentprofile>
>>
>> > @contentProfile
>>
>> What about a list of one or more content profile designator URIs,
>> each indicating conformance to a content profile, e.g.
>>
>> <tt ttp:contentProfile="http://example.noname/profile1
>> http://example.noname/profile2">
>>
>> Best,
>>
>> -- Pierre
>>
>> On Thu, Jul 11, 2013 at 9:16 AM, Timed Text Working Group Issue
>> Tracker <sysbot+tracker@w3.org <mailto:sysbot%2Btracker@w3.org> > wrote:
>> > ISSUE-261: signaling docoument profile conformance is separate from
>> > decoder presentation requirements [TTML.next]
>> >
>> > http://www.w3.org/AudioVideo/TT/tracker/issues/261
>> >
>> > Raised by: Mike Dolan
>> > On product: TTML.next
>> >
>> > The profile element and attribute currently signal a feature set
>> > that a decoder must implement in order to reasonably present the
>> > document. Although it also hints at what features the document
>> > instance may include, it does not signal document instance conformance
today.
>> >
>> > There is currently no mechanism to signal what profile a document
>> > instance conforms to (e.g. sdp-us).
>> >
>> > It is desirable to add this capability to TTML. However, simply
>> > adding this semantic to the existing profile element and attribute
>> > overly constrains the existing (decoder) and desired (document)
>> > semantics. It is unreasonable to require that the single element
>> > and attribute simultaneously signal both. For example, the fact
>> > that a document instance conforms to dfxp-full does and should not
>> > automatically infer that an sdp-us decoder could not properly
>> > present it. That is instance dependent. This situation is aggravated
when multiple profiles are involved.
>> >
>> > Some means must be defined to separately signal these different
>> > semantics. For example, we could create a new element and attribute
>> > - <ContentProfile> and contentProfile.
>> >
>> >
>> >
>> >
>>
>
Received on Monday, 15 July 2013 15:49:19 UTC