Review references.

[mikedo]

See also #293

NORMATIVE REFERENCES:

[GPS] This cite is to an unusual source. But for both UTC and GPS, a reference to the technology is not really all that helpful. It’s only important that one know unambiguously which it is. The one required bit of information needed by transformation processors is the current in force leap seconds, which is not listed. It turns out that an authoritative normative reference for this has an equally sketchy pedigree. I think GPS and UTC references are arguably both not essential except for the leap second aspect.

[HTML5] - As we all know, the real spec for HTML5 is at whatwg.org. Although citing the old W3C Rec is “tidy”, it’s not technically accurate. At least add an informative reference to whatwg and consider what to do longer term.

[SMPTE 12M] – Obsoleted by: ST 12-1:2008 - SMPTE Standard - For Television — Time and Control Code, http://ieeexplore.ieee.org/document/7289820/

[URI] – Obsoleted by RFC 3986. Also, in general, the more helpful RFC URLs are now here, e.g. https://tools.ietf.org/html/rfc3986

OTHER REFERENCES:

[CMAF] is not yet published and at best is the first of the year. But the citation in 12.4.1 is a bit misleading. CMAF just points to 14496-30 and defines some signaling information. I would either remove this or add additional context about why it is relevant.

[ISOBMFF] – Although just a label, the rest of the world uses this acronym to mean specifically, 14496-12. I’d recommend changing it to “ISO-TT” or something else to avoid reader confusion.

[SMPTE 170M] – Obsoleted by: ST 170:2004 - SMPTE Standard - For Television — Composite Analog Video Signal — NTSC for Studio Applications, http://ieeexplore.ieee.org/document/7291416/

[SMPTE 2052-11] – use the full title: RP 2052-11:2013 - SMPTE Recommended Practice - Conversion from CEA-708 Caption Data to SMPTE-TT and add: http://ieeexplore.ieee.org/document/7290363/

GENERAL:

I think dates/versions are generally essential on normative references with the exception of reference to code point registries.

Conversely, using undated informative references is OK as long as the title is not likely to change. But to that point, note the SMTPE title changes. Readers can always decide to read newer versions of informative references.

Wherever possible it is good to provide a URL to acquire the citations.

[nigelmegitt]

Thanks @mikedo , sorry for the slow response.

I will not accept a reference to the WHATWG HTML draft unless we depend on something in that document that is not in the W3C HTML spec. And even then, I'd want to take a close look at it.

Does the change to SMPTE 12M to ST 12-1:2008 contain any normative changes that would invalidate the existing reference? I have a dim recollection from discussing this in the past that it might do.

I also noticed in #474 that the URI reference is out of date, but it's slightly complicated by the fact that our dependency on the URI actually comes via xsd:anyURI in the XML Schema spec. I made a proposal at #474 (comment)

Re CMAF, that publication timeline fits with ours, so I think we should leave it in and update the reference when CMAF is published.

I think given that 14496-30 is the applicable part of the ISOBMFF spec for timed text, it's okay to keep it as is, but I wouldn't object to changing the label. I don't like ISO-TT - maybe ISOBMFF30?

I'm happy with the other changes suggested by @mikedo .

I think dates/versions are generally essential on normative references with the exception of reference to code point registries.

+1 with the "where possible" caveat especially applicable to the URLs.

[mikedo]

I will not accept a reference to the WHATWG HTML draft...

You object to adding an informative reference? Can you please elaborate on the rationale? Although I was additionally calling attention to a serious disconnect between Rec process/procedures and the real world of HTML, that was a long term philosophical question. There are many technical differences between the two specifications. I think ignoring whatwg entirely does not serve the reader. Pointing only to the old dated W3C Rec is neat and tidy specsmanship, but completely broken technically. I was proposing a compromise where we acknowledge (informatively) the whatwg spec, which is the "real" one, technically.

Does the change to SMPTE 12M to ST 12-1:2008 contain any normative changes...

Not intentionally.

Re CMAF, that publication timeline fits with ours, so I think we should leave it in and update the reference when CMAF is published.

There is no harm in ultimately (informatively) referencing CMAF, but it is not available today. I'd prefer to omit it until it is actually available as the date is very uncertain. But if it is desirable to add a placeholder that we may have to remove, then it needs a caveat editorial note that says it is not yet available.

[nigelmegitt]

You object to adding an informative reference? Can you please elaborate on the rationale?

The point is that if there is something we depend on that is in the W3C HTML spec then we should prefer to reference that because it has stronger process behind it. By the way, I don't think it is factually accurate that the whatwg spec is the "real" one - I've been asking about it lately and the common view is that there are parts of the whatwg spec that are derived from things developed in W3C Working Groups and parts of the W3C HTML spec that are derived from things developed in whatwg. It simply isn't a straightforward relationship, and it doesn't help anyone for us to suggest that there is one right answer. And of course, two things that both exist are both "real"!

Does the change to SMPTE 12M to ST 12-1:2008 contain any normative changes...

Not intentionally.

OK, I'm happy to update it then.

it needs a caveat editorial note that says it is not yet available.

Works for me.