search

ietf-wg-cellar / ebml-specification

the specification for the EBML format
Creative Commons Attribution 4.0 International
70 stars 24 forks source link

address conflict between unwritten minOccurs attribute and implementation note #292

Open dericed opened 4 years ago

dericed commented 4 years ago

After a change in the EBML specification to clarify this, a corresponding change may be needed in the matroska specification.

See discussion on this issue at https://github.com/cellar-wg/matroska-specification/pull/272#issuecomment-545003625

robUx4 commented 4 years ago

A formatting like this with a special keyword <unset> should work for all cases:

minOccurs: <unset>
               see implementation notes for details
minOccurs: 1
               see implementation notes for details
dericed commented 4 years ago

This is similar to my earlier use of "see note". I'd suggest to not include brackets within the special keyword.

robUx4 commented 4 years ago

As with any keyword it must not be mistaken for a value. It could be used as a string, in which case it should be around double quotes (we should mention that in the specs if not already ?). So I guess no brackets would work too. It wouldn't be confused with a string value.

dericed commented 4 years ago

The other way to address it would be to adjust this line:

If the minOccurs attribute is not present then that EBML Element has a minOccurs value of 0.

Perhaps:

If the Element has an implementation_note with a note_attribute of "minOccurs" than that implementation_note describes the minOccurs and the minOccurs attribute MUST be ignored, else if the minOccurs attribute is not present then that EBML Element has a minOccurs value of 0.

robUx4 commented 4 years ago

I think it's too specific to how we use it for now. For example an element may be mandatory (minOccurs=1) by default and implementation_note specify when it's not mandatory or when it has to be found twice.

More generally I think the implementation_note should specify each value.

Not sure the value should actually be set with the "regular" value in XML Schema as it can't really be mechanically interpreted. That would be misleading.

robUx4 commented 4 years ago

(replying to myself) Not setting the minOccurs means it uses the default value (0). Also the path requires an EBMLMinOccurrence, if not written it means the value is 0. There is no <unset> value.

So either we add the concept of unset value (- sign for EBMLMinOccurrence/EBMLMaxOccurrence for example) or we have to pick the best/most common default value and explain in which case the value differs in implementation_note.

I think the unset option is better because it doesn't mislead the reader and programs that would parse the path to verify the validity of an element and would have no way of parsing the human-readable text implementation_note to tell when the default value is OK or not.

dericed commented 4 years ago

I can't remember but is there a reason to have EBMLMinOccurrence/EBMLMaxOccurrence within the path as they are redundant to the minOccurs/maxOccurs attributes?

robUx4 commented 4 years ago

I do not remember either and I don't see a reason why it's needed. It actually makes parsing the path harder and the occurence can be read from other attributes in the . So I'm OK with removing it totally. Now that I can handle XSLT, I can see how easier it is to go that way. I even had to add a check so the path values match the attributes.

Removing that from the path would make an "unset" value easier to handle.

The GlobalParentOccurence would still remain as there is no other equivalent.

dericed commented 4 years ago

I agree with the idea, leave GlobalParentOccurence and remove EBMLEltOccurrence and its components, though should be careful if any documentation associated with EBMLEltOccurrence should be moved to minOccurs and maxOccurs.