search

SMPTE / st429-20

Public CD of SMPTE ST 429-20 1ED
Other
0 stars 0 forks source link

Normative References #6

Closed jpviollet closed 3 years ago

jpviollet commented 3 years ago

In the ST 377-1:2009 vs ST 377-1:2019 diff file distributed, a comment indicates the following about the normative references changes: “Assume no substantive changes since the MXF version number was not changed when these normative references were updated.”

As we ultimately need to compare ST 377-1:2019 and ST 377:2004, has any evaluation of normative references differences been done between ST 377-1:2009 (or ST 377-1:2019) and ST 377:2004? In fact, the version number argument is not valid anymore as ST 377:2004 has a different one.

palemieux commented 3 years ago

Below is a list of the differences between the normative references in ST 377-1:2019 and ST 377:2004.

Changed

377:2004 377-1:2019
SMPTE 336M–2001, Television – Data Encoding Protocol Using KLV SMPTE 336M–2007, Data Encoding Protocol Using Key-Length-Value

Added in ST 377-1:2019

Removed in ST 377-1:2019

palemieux commented 3 years ago

It looks like ST 336 underwent quite a few changes:

Redline from ST 336:2001 and ST 336:2007

The redline is across two PDF documents, one which contains two columns of text.

Some additional data points:

jpviollet commented 3 years ago

It feels the group would need to discuss the argument about ST336 – I was not able to check ST336 in detail myself yet. However, my initial comment was not meant to mostly get a diff of the list of normative references between the two standards, it was intended to know what the impact of these differences is. Does the answer imply that the only possible impact is from ST336?

palemieux commented 3 years ago

Does the answer imply that the only possible impact is from ST336?

Yes.

jpviollet commented 3 years ago

This would then have to be discussed by the group as well then – I did not have a chance to look into all these reference differences yet, even if some, at first glance, indeed don’t seem a problem.

jpviollet commented 3 years ago

Thinking about normative references, I understand that we are writing this document to avoid having ST 377:2004 as a normative reference in the other D-Cinema standards. However, it feels for this specific document itself, we may need to have ST 377:2004 listed in normative references as we do refer to it - otherwise, maybe some could argue that references are not really authoritative, and ST 377-1:2019 is actually the only MXF version normatively referenced by this document.

Thinking further, it feels we should even add a statement like the following one: "In case of conflict between this document and SMPTE ST 377:2004, SMPTE ST 377:2004 shall be authoritative."

Does this make sense?

palemieux commented 3 years ago

A key objective of the project is to remove the need to reference ST 377:2004.

I think the intent of the document is clear, per the discuss at #5, so that the document can be readily updated as divergences, if any, are found.

jpviollet commented 3 years ago

Most ST377:2004 references are most likely just fine without ST377:2004 listed as normative reference. However, what about references like in section 5.12:

"The default values for the Track Name item specified in SMPTE ST 377:2004 apply, including, but not limited to:"

This should be understood as a "requirement", over-writing how ST377-1:2019 is written, and we are not even providing the full list of tracks - it says "including, but not limited to:"

palemieux commented 3 years ago

However, what about references like in section 5.12: [...] This should be understood as a "requirement",

It sounds like list of divergences in SEction 5.12 should be exhaustive.

P.S.: This should be open as a separate issue.

jpviollet commented 3 years ago

Ok, I am opening a separate issue.

palemieux commented 3 years ago

Summary based on 2021-06-10 discussion:

jpviollet commented 3 years ago

Based on considerations from the DG, as summarized by Pierre above, it feels fair to close this comment - new case would be re-open if an issue is ever discovered in the future. Thank you.