W3C home > Mailing lists > Public > public-tt@w3.org > May 2014

Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0]

From: Pierre-Anthony Lemieux <pal@sandflow.com>
Date: Fri, 23 May 2014 13:09:58 -0700
Message-ID: <CAF_7JxCKKi0w7nX18byveHgPP06vq=k7EHakQC0v_uK+bQqDLQ@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
Hi Nigel,

Re: point 1).

>  I can't see where in the SMPTE-TT document the syntax is defined that
> is used to describe the <image> element

Per Section 6.4 in IMSC, "smpte:image shall not be used."

Perhaps you meant something else? If not, I do not believe that the
lack of definition of the smpte:image element can server as a
motivation for the proposal.

Thanks,

-- Pierre

On Fri, May 23, 2014 at 10:45 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> This issue can not be resolved by general recognition that W3C sometimes references
> SMPTE publications.
>
> It needs two things to be confirmed:
> 1) that the referenced content is suitable to be referenced normatively
> 2) that the specific document can be accepted from a licensing perspective.
>
> I have already explained my reservations with the content in its current form though re point 1.
>
> Nigel
>
>
>> On 23 May 2014, at 17:56, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
>>
>> There is precedence for referencing SMPTE specifications in W3C, e.g.
>> SMPTE 12M is a normative reference in TTML 1.
>>
>> Furthermore, no specific information has been offered that "the
>> licensing status of those externally-developed technologies could
>> become a barrier to implementation of the technology according to the
>> W3C Royalty-Free (RF) Licensing Requirements."
>>
>> So, as it stands, I see no reason to take action.
>>
>> Thanks,
>>
>> -- Pierre
>>
>> On Fri, May 23, 2014 at 7:44 AM, Timed Text Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>> ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0]
>>>
>>> http://www.w3.org/AudioVideo/TT/tracker/issues/320
>>>
>>> Raised by: Nigel Megitt
>>> On product: TTML IMSC 1.0
>>>
>>> Amongst other sections, §4.2, §6.2.1 and Appendices B.5 and C.1 make normative reference to SMPTE-2052-1 [1], however that document makes clear that it is possible that some parts of it may be subject to patent rights. Can we normatively reference something when we can't establish the licensing status of it? Note that SMPTE are not current members of this WG.
>>>
>>> The W3C Patent Policy FAQ says something about this, in question 32 [2] - to quote:
>>>
>>>> "32. Can a W3C Recommendation normatively refer to technology developed outside W3C with licensing terms that differ from those of the W3C Patent Policy?
>>>>
>>>> Yes. W3C Recommendations may include normative references to standards or technologies developed outside of W3C. However, the Working Group should keep in mind the importance of royalty-free implementations of Web standards. In the event it becomes clear that the licensing status of those externally-developed technologies could become a barrier to implementation of the technology according to the W3C Royalty-Free (RF) Licensing Requirements, W3C may choose not to publish the document or may launch a PAG."
>>>
>>> On this basis we (this WG) should keep in mind the implications and consider a change.
>>>
>>> One question I would ask is: is the referenced feature well defined? I can't see where in the SMPTE-TT document the syntax is defined that is used to describe the <image> element, so I'm not 100% clear what it means, especially because what looks like the imageType attribute is shown without an '=' that is present elsewhere on similar attributes (presumably a typo). The XSD schema is marked explicitly as non-normative.
>>>
>>> On that basis SMPTE 2052-1 appears to make no normative statement defining the contents and structure of the element on which the feature is based, which isn't ideal (even if a common-sense reading is probably correct). It's even less clear how the backgroundImage attribute is defined because it seems permitted to include no value, or if a value is specified it's listed as the undefined 'uri-specification' but seems to be a reference to an xml:id defined in an <image> element.
>>>
>>> I'm concerned that we are making a normative reference from IMSC to an external document that is not specified to the level of precision that we'd seek in a W3C recommendation.
>>>
>>> I'd be open to one of a variety of remediations here, including in no order of preference:
>>> * removal of the image profile altogether;
>>> * redefinition in IMSC of the image element and backgroundImage attribute in the relevant ttml namespace;
>>> * requesting that SMPTE edits 2052-1 to make the definitions clearer and (optionally and preferably) to clarify the licensing status so that we can continue to reference it;
>>> * other options I haven't thought of.
>>>
>>>
>>> Incidentally, IMSC 1 §B.1 suggests that all the subsequent feature extension designations are in the TTML extension namespace but this is not true for B.5 which is in the SMPTE-TT namespace (which by the way happens to return a "Not Found" response page, for both the one in the text in the 2052-1 document §5.8 or the other different one in Table 11).
>>>
>>>
>>> [1] https://www.smpte.org/sites/default/files/st2052-1-2010.pdf
>>> [2] http://www.w3.org/2003/12/22-pp-faq.html#outside-normative-ref
>>
>
>
> -----------------------------
> 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.
> -----------------------------
Received on Friday, 23 May 2014 20:10:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:15 UTC