ISSUE-320: Is normative SMPTE 2052 reference okay?

Is normative SMPTE 2052 reference okay?

Is normative SMPTE 2052 reference okay?

State:

CLOSED

Product:

TTML IMSC 1.0

Raised by:

Nigel Megitt

Opened on:

2014-05-23

Description:

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

Related Actions Items:

No related actions

Related emails:

1. {minutes} TTWG Meeting 5/6/2014 (from nigel.megitt@bbc.co.uk on 2014-06-05)
2. Re: {minutes} TTWG Meeting 29/5/2014 (from pal@sandflow.com on 2014-06-05)
3. RE: {agenda} TTWG Meeting 5/6/2014 (from mdolan@newtbt.com on 2014-06-04)
4. {agenda} TTWG Meeting 5/6/2014 (from nigel.megitt@bbc.co.uk on 2014-06-04)
5. Re: {minutes} TTWG Meeting 29/5/2014 (from glenn@skynav.com on 2014-05-30)
6. Re: {minutes} TTWG Meeting 29/5/2014 (from silviapfeiffer1@gmail.com on 2014-05-30)
7. Re: {minutes} TTWG Meeting 29/5/2014 (from pal@sandflow.com on 2014-05-29)
8. {minutes} TTWG Meeting 29/5/2014 (from nigel.megitt@bbc.co.uk on 2014-05-29)
9. {agenda} TTWG Meeting 29/5/2014 (from nigel.megitt@bbc.co.uk on 2014-05-28)
10. Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from glenn@skynav.com on 2014-05-24)
11. Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from pal@sandflow.com on 2014-05-23)
12. Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from pal@sandflow.com on 2014-05-23)
13. Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-05-23)
14. Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from pal@sandflow.com on 2014-05-23)
15. Re: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from nigel.megitt@bbc.co.uk on 2014-05-23)
16. RE: ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from mdolan@newtbt.com on 2014-05-23)
17. ISSUE-320 (Is normative SMPTE 2052 reference okay?): Is normative SMPTE 2052 reference okay? [TTML IMSC 1.0] (from sysbot+tracker@w3.org on 2014-05-23)

Related notes:

Display change log