Re: [Cellar] On the multiplicity of Info elements

[Steve Lhomme <[e-mail]>]

2016-01-10 19:35 GMT+01:00 Dave Rice <[e-mail]>:
>
>> On Jan 6, 2016, at 2:12 PM, Sebastian G. <bastik> wrote:
>>
>> 06.01.2016, 08:06 Dave Rice:
>>> Here is a draft for an EBML Schema Attribute to be used in the
>>> definition of EBML Elements for what I’m referring to as
>>> Identically-Recurring Elements.
>>>
>>> ==== A boolean to express if the EBML Element may occur within its
>>> Parent Element more than once but that each recurrance within that
>>
>> Is 'recurrance' spelled correctly? (Not a native speaker). 'recurrence'
>> is suggested as search term suggestion.
>
> fixed
>
>>> Parent Element MUST be identical both in storage and semantics. Such
>>> Elements are referred to as Identically-Recurring Elements. In this
>>> case, identical copies of an EBML Element are permitted to be stored
>>> multiple times within the same Parent Element in order to increase
>>> data resillience and optimize the use of EBML in transmission.
>>
>> 'resillience' seems to have an error. 'resilience’.
>
> fixed
>
>>> Identically-Recurring Elements SHOULD include a CRC-32 Element as a
>>> Child Element. If a Parent Element contains more than one copy of an
>>> Identically-Recurring Element which includes a CRC-32 Child Elememnt
>>
>> s/Elememnt/Element
>
> fixed
>
>>> then the first instance of the Identically-Recurring Element with a
>>> valid CRC-32 value should be used for interpretation. If a Parent
>>> Element contains more than one copy of an Identically-Recurring
>>> Element which does not contain a CRC-32 Child Elememnt then the first
>>
>> s/Elememnt/Element
>
> fixed
>
>> 'If a Parent Element contains more than one copy of an
>> Identically-Recurring Element which does not contain a CRC-32 Child
>> Element "or if CRC-32 Child Elements are present but neither of those
>> are valid" then the first instance of the Identically-Recurring Element
>> should be used for interpretation.'
>>
>> I took your sentence and added (noted by "") the case something would
>> contain CRCs, but neither of them would be valid. Feel free to ignore
>> this suggestion. It might be a rare case.
>>
>> It is certainly possible to have it as separate sentence. Maybe it makes
>> it easier to read. Maybe even easier to understand.
>>
>>> instance of the Identically-Recurring Element should be used for
>>> interpretation. If the `identical` attribute is not expressed for
>>> that Element then that Element is considered to not have a
>>> requirement for identical expression within the same Parent Element.
>>> The `identical` attribute is only valid if the Element is not set to
>>> `multiple`, otherwise the `identical` attribute shall be ignored.
>>> ====
>>>
>>> The text may be seen in context with the other attributes at
>>> https://github.com/MediaArea/ebml-specification/blob/d108c14d1f1c748d1f3f50e58d4057208325f892/specification.markdown#ebml-schema-element-attributes
>>>
>>> Some pending questions:
>>> - Should Identically-Recurring Elements recommend or mandate inclusion of a CRC-32? I suggestion recommend and not mandate for reverse compability.
>>
>> Backward compatibility seems to be a higher goal than CRCs. I think it
>> should be even possible to play a file without checking CRCs, which does
>> not contradict having CRCs in the first place.
>
> I agree.

The backward compatibility is important so that older files are
handled correctly by future (stricter) parsers. In the case where a
recurring element doesn't have any CRC, I don't think future parsers
should discard such elements. So we could still make it mandatory and
keep backward compatibility. There will be plenty of other cases for
old files to not be compliant to the current/future specs and still
play fine.

>> Like Timothy B. Terriberry points out, reasons for not having CRCs on
>> those elements should be given in the specification.
>
> Based on Tim and Sebastian’s comments I extended the sentence to be:
>
> "Identically-Recurring Elements SHOULD include a CRC-32 Element as a Child Element; this is especially recommended when EBML is used for long-term storage or transmission.”
>
> Listing reasons to not have a CRC Child Element seems awkward. Realistically I think the primary reason that CRC elements are not used is because many muxers don’t support adding them, although the EBML specification has long contained: "All level 1 elements SHOULD include a CRC-32.” Instead of addressing reasons why not I added some reasons for why with references to ong-term storage and transmission.
>
>>> - Is 'Identically-Recurring Elements’ a decent short name for these types of Elements?
>>
>> I have no objection. IRE could be used when talking about those
>> elements, unless it is within official documents.
>>
>>> - Should the ‘identical’ attribute apply to only Master-elements? I think it could be open. I could see scenarios to place the CRC-32 both at the beginning and end of the Parent Element.
>>
>> I have not enough knowledge to make an informed statement.
>
> Unless there’s a good reason to do so, I won’t restrict the ‘identical’ attribute to certain Element Types, thus the specifications for EBML formats can decide how to use this.

If CRC is mandatory, then it's not possible. If it's not mandatory
it's possible to have unique elements duplicate. But then how do you
know which one to use ? Also having unique elements repeated seem
bogus and some parsers may not like that. It's a contradiction to what
"unique" means.

>>> - I’m thinking that ‘multiple’ means the Element may recur within its Parent Element and means that there are multiple semantics. I suggest that ‘identical’ Elements not be ‘multiple’ as an ‘identical’ Element recurs but only with a single and non-multiple semantic meaning. OK?
>>
>> I have not enough knowledge to make an informed statement.
>>
>>> - If there are multiple copies of identical Elements, I wrote in the draft that if there’s a CRC than the first copy with valid CRC be used, else the first copy be used. Potentially we could say first valid copy be used, but then need to say fully what valid means.
>>
>> I'm neutral, but agree that if just valid is used it would have to be
>> explained what valid means.
>>
>>> - I agree that an identical Element should not be used to change the semantics over time.
>>
>> Agreed.
>
> Here is a new version for review:
>
> Definition for a new EBML Schema Attribute: identical
> ===============
> A boolean to express if the EBML Element may occur within its Parent Element more than once but that each recurrence within that Parent Element MUST be identical both in storage and semantics. Such Elements are referred to as Identically-Recurring Elements. In this case, identical copies of an EBML Element are permitted to be stored multiple times within the same Parent Element in order to increase data resilience and optimize the use of EBML in transmission. Identically-Recurring Elements SHOULD include a CRC-32 Element as a Child Element; this is especially recommended when EBML is used for long-term storage or transmission. If a Parent Element contains more than one copy of an Identically-Recurring Element which includes a CRC-32 Child Element then the first instance of the Identically-Recurring Element with a valid CRC-32 value should be used for interpretation. If a Parent Element contains more than one copy of an Identically-Recurring Element which does not contain a CRC-32 Child Element or if CRC-32 Child Elements are present but none are valid then the first instance of the Identically-Recurring Element should be used for interpretation. If the `identical` attribute is not expressed for that Element then that Element is considered to not have a requirement for identical expression within the same Parent Element. The `identical` attribute is only valid if the Element is not set to `multiple`, otherwise the `identical` attribute shall be ignored.
> ===============
>
> Dave Rice
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman