RE: more profile confusion ( ISSUE-170)

Hmm. The lack of clarity for me is that “profile” is overloaded in that sentence (read further down below).  As drafted, it implies a <profile> element must be defined *somewhere*.   I think we all agree that was not the intent.  For example, the set of features can be defined using English in a specification with no <profile> element defined anywhere. Personally, I wasn’t concerned about “document interchange context”, but sure, OK to clarify that, too.

 

I’m OK with a Note, but we need to adjust the sentence in an upcoming editor’s draft.  I proposed a specific edit (again below).

 

Regards,

 

                Mike

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Wednesday, June 13, 2012 6:50 AM
To: Andreas Tai
Cc: public-tt
Subject: Re: more profile confusion ( ISSUE-170)

 

 

On Wed, Jun 13, 2012 at 5:45 AM, Andreas Tai <tai@irt.de> wrote:

Thanks for taking this up. Background of the question is still, what the interpretation should be if no profile element or attribute was specified in a TTML document.

 

Currently I think the text is clear, and the answer depends upon whether the document interchange context specifies (in some way unknown to the TTML specification, i.e., in a non-standardized manner) a profile or not; if yes, then that profile applies, if no, then the transformation profile applies.

 

In any case, we have agreed to further elaborate on the meaning of document interchange context via a note.

 


It would be interesting to know if current TTML processors are conformant TTML transformation and/or conformant TTML presentation processors.

 

>From the perspective of the TTML spec, it depends on whether such processors "claim" conformance or not. One could ask which processors:

1. don't claim conformance and aren't conformant
2. don't claim conformance, but are conformant
3. claim conformance, but are not conformant
4. claim conformance and are conformant

The third of these is prohibited by the spec; however, the other three are permitted. Since we don't define a 'generic' profile (for an implementation that satisfies only the generic processor requirements), the second and fourth are ruled out as well. So, for such a processor, no conformance claim could be made with respect to the currently defined profiles, and thus, only the first above applies.

 


Best regards,

Andreas
Am 13.06.2012 05:04, schrieb Glenn Adams: 

 

On Tue, Jun 12, 2012 at 9:21 AM, Andreas Tai <tai@irt.de> wrote:

Thanks for the helpful analysis, Glenn. 

Yes, at the end it is about a conformant TTML generic processor. Is it possible that a TTML generic processor does not support the profile feature (and hence is not a conformant transformation nor presentation processor)?

 

It is an open question in my mind, since, to my knowledge, we never considered the idea of a TTML processor that conformed only to the generic requirements, but not to either transformation/presentation processor requirements. However, I don't see anything in TTML 1.0 that rules out such an implementation, it's just that it could not claim to be either a conforming transformation or presentation processor.

 


Am 11.06.2012 19:42, schrieb Glenn Adams: 

 

On Mon, Jun 11, 2012 at 9:27 AM, Andreas Tai <tai@irt.de> wrote:

>From my reading the profile mechanism is a TTML feature itself and can be optional. So if the context make the profile mechanism optional it is not needed for a TTML processor to implement it. Am I correct?

 

yes, #profile is an enumerated feature [1]

 

[1] http://www.w3.org/TR/ttaf1-dfxp/#feature-profile

 

however, it is also a mandatory feature for both transformation [2] and presentation [3] profiles

 

[2] http://www.w3.org/TR/ttaf1-dfxp/#feature-transformation-mandatory-table

[3] http://www.w3.org/TR/ttaf1-dfxp/#feature-presentation-mandatory-table

 

finally, a conformant transformation processor [4] and a conformant presentation processor [5] are obliged to support the transformation and presentation profiles, respectively

 

[4] http://www.w3.org/TR/ttaf1-dfxp/#conformance-transformation-processor

[5] http://www.w3.org/TR/ttaf1-dfxp/#conformance-presentation-processor

 

so, when you ask "it is not needed for a TTML processor to implement it", then the answer is yes if you mean either a "conformant TTML transformation processor" or a "conformant TTML presentation processor"

 


Furthermore it maybe a possibility for TTML 1.1 to reflect on the profile mechanism with respect to it´s implementation by TTML users/processors.

 

what I think you may be asking here is whether a TTML processor may be a "conformant TTML generic processor" [6], but neither a (conformant) transformation processor nor a (conformant) presentation processor; is that correct?

 

[6] http://www.w3.org/TR/ttaf1-dfxp/#conformance-generic-processor

 


Best regards,

Andreas

Am 06.06.2012 18:28, schrieb Glenn Adams: 

ok, that's a reasonable clarification; i agree that "if the document interchange context does not specify a profile" is not sufficiently precise

On Wed, Jun 6, 2012 at 10:07 AM, Michael A Dolan <mdolan@newtbt.com> wrote:

I agree with the spirit of what you say.  But as drafted, the Recommendation is using a defined term, “profile”, so I disagree that it does not, as drafted, require a profile document.  That’s the issue.  Even if you read it differently, the point is that others read it the same as I do, and therefore it needs clarification.  I proposed “conforming subset or something more generic”.  How about “…and if the document interchange context does not specify a profile document, or other equivalent set of feature designators,…”

 

Whatever wording works for you is fine with me.  

 

Regards,

 

                Mike

 

 

From: Glenn Adams [mailto:glenn@skynav.com] 
Sent: Wednesday, June 06, 2012 8:49 AM
To: Michael A Dolan
Cc: public-tt@w3.org


Subject: Re: more profile confusion

 

 

On Wed, Jun 6, 2012 at 8:51 AM, Michael A Dolan <mdolan@newtbt.com> wrote:

Another troubling profile sentence in 5.2 was called to my attention:

 

If neither <http://www.w3.org/TR/ttaf1-dfxp/#parameter-attribute-profile> ttp:profileattribute nor <http://www.w3.org/TR/ttaf1-dfxp/#parameter-vocabulary-profile> ttp:profileelement is present in a TTML document instance, and if the document interchange context does not specify a profile, then the DFXP Transformation profile applies.

 

A “document interchange context” might well fully define a conforming subset definition, but it may or may not formally define a “profile” as defined in the recommendation.

 

An instance document would more likely declare its conformance by some other means, such as reference to a schema, or using xml-model, or simply by its context (e.g. a branded MP4 file).

 

When we get to overhauling the profile language, we should fix the above, minimally replacing “profile” with “conforming subset” or something more generic that does not imply a TTML Profile definition is required.

 

Actually, I think I do not agree with this. The point of the above cited language is to ensure that the applicable profile is well defined, since it is necessary to know the applicable profile in order to perform processing in a compliant manner.

 

As reference to a profile defined/specified by a document interchange context is intended to serve as a out-of-band protocol to allow determination of which profile applies. It does not mean that a ttp profile document must be available for either author or client, it means that the information that would be included in such a document is known is some manner, whether or not it is defined in a profile file.

 

Finally, the phrase "conforming subset" has no formal meaning/use in TTML at present other than indirectly through the use of profile definitions.

 

 






-- 
------------------------------------------------
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 | Email: tai@irt.de
------------------------------------------------
 
registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------

 






-- 
------------------------------------------------
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 | Email: tai@irt.de
------------------------------------------------
 
registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------

 






-- 
------------------------------------------------
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 | Email: tai@irt.de
------------------------------------------------
 
registration court&  managing director:
Munich Commercial, RegNo. B 5191
Dr. Klaus Illgner-Fehns
------------------------------------------------

 

Received on Wednesday, 13 June 2012 14:03:56 UTC