Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element type default values (not the attribute "default") #403

Open
hubblec4 opened this issue Mar 31, 2021 · 5 comments
Open

Element type default values (not the attribute "default") #403

hubblec4 opened this issue Mar 31, 2021 · 5 comments
Labels
bug errata-rfc8794 Errors found in RFC 8794
Milestone

Comments

@hubblec4
Copy link

hubblec4 commented Mar 31, 2021

The specs say that all non-Master element types have a default value if the data size = 0.

For example the Unsigend Integer Element has a type default value of 0.
This means in Matroska when the ChapterTimeStart element is present in a file but have no data(data size length = 0), I can use a value of 0 for the start time?

The ChapterTimeStart element has no attribute "default" but there is a default value because the element type default value can be used instead.

The ChapLanguageIETF element is a type of String and has restriction to the value. This element must not have empty data, but the String element type default value is an empty string.
This means when such an element is in the file without data -> thats illegal?!

Master elements:
In the ebml lib code is also a default value coded: when the Master element has no data (no sub elements in the list) then is the default = true.

bool IsDefaultValue() const {
return (ElementList.size() == 0);
}

This is fine to me, because no data means an empty master element.
The problem here is, when the Master element has elements with mandatory attribute without default value.

A conclusion for me is:
All elements have a default value.
And for some elements is the default value illegal.

How wrong am I with that?

@robUx4
Copy link
Contributor

robUx4 commented Apr 4, 2021

The specs says

An Element Data Size with all VINT\_DATA
bits set to zero indicates that the Element Data is zero octets in
length. Such an EBML Element is referred to as an Empty Element. If an Empty
Element has a default value declared, then the EBML Reader **MUST** 
interpret the value of the Empty Element as the default value. If an Empty
Element has no default value declared, then the EBML Reader **MUST**
use the value of the Empty Element for the corresponding EBML Element Type of
the Element ID, 0 for numbers and an empty string for strings.
  • I can use a value of 0 for the start time?
    yes
  • This means when such an element is in the file without data -> thats illegal?!
    no, a length of 0 with no default value is an empty string
  • The problem here is, when the Master element has elements with mandatory attribute without default value.
    this is an issue that should be raised in libebml, not here
  • All elements have a default value.
    no, the spec clearly says EBML Elements that are Master Elements **MUST NOT** declare a default value.
  • And for some elements is the default value illegal.
    yes, for all Master elements

There is an issue with how to interpret an empty Master element. It's the one type that is not mentioned above and yet is allowed to be empty:
A Master Element **MUST** declare a length in octets from zero to VINTMAX or be of unknown length.

I think we're missing an explanation on how to handle this case. IIRC in libebml the mandatory children with a default value are automatically added to an EbmlMaster on creation, so it's always there with the default value unless overwritten. IMO that's the way to go: "empty Master Elements should be interpreted with their mandatory elements present as empty elements (so using 0 /empty string/empty master)."

This is related to the issue on how to handle mandatory elements #394.

@robUx4 robUx4 added bug errata-rfc8794 Errors found in RFC 8794 labels Apr 4, 2021
@hubblec4
Copy link
Author

hubblec4 commented Apr 4, 2021

This means when such an element is in the file without data -> thats illegal?!
no, a length of 0 with no default value is an empty string

Yes, for EBML is this correct (an empty string is used), but not for Matroska, because the ChapLanguageIETF must not be empty.

All elements have a default value.
no, the spec clearly says EBML Elements that are Master Elements MUST NOT declare a default value.

Yes, no attribute default value can be used for MasterElements, but the type default value says: type default is when the MasterElement has no sub-elements -> empty MasterElement

And for some elements is the default value illegal.
yes, for all Master elements

The term "default value" was no correct. I meant the element type default value.
For example the ChapLanguageIETF: the type default value is an empty String, but an empty String is not allowed for the ChapLanguageIETF element.
But yes, this is more an issue for the libMatroska -> we should set a default value for this element -> en.

@robUx4
Copy link
Contributor

robUx4 commented Apr 5, 2021

This means when such an element is in the file without data -> thats illegal?!
no, a length of 0 with no default value is an empty string

Yes, for EBML is this correct (an empty string is used), but not for Matroska, because the ChapLanguageIETF must not be empty.

There is nothing in the current spec that says ChapLanguageIETF must not be empty. Maybe we should add a range value (not empty), but this is currently not the case. This leads to an interresting point we have to check: all strings with no default value can used as empty element or not. If not they must be marked as such.

And for some elements is the default value illegal.
yes, for all Master elements

The term "default value" was no correct. I meant the element type default value.
For example the ChapLanguageIETF: the type default value is an empty String, but an empty String is not allowed for the ChapLanguageIETF element.

Not yet.

But yes, this is more an issue for the libMatroska -> we should set a default value for this element -> en.

Definitely not. libmatroska should not take the liberty to invent default values for elements. And we already established that the default value of "en" for ChapLanguage was a bad idea too.

@robUx4
Copy link
Contributor

robUx4 commented Apr 5, 2021

Rather than the range we should use length=">0" to mark a string not possible as empty. It's already used for the EBML DocType.

@robUx4
Copy link
Contributor

robUx4 commented Apr 5, 2021

Given some elements are not legal as empty elements (that may not just be for strings, binary UIDs cannot be empty either), some Master elements also cannot be empty. This is already related to the length constraints which should also be mentioned in the Empty String section.

@robUx4 robUx4 added this to the new-rfc milestone Jul 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug errata-rfc8794 Errors found in RFC 8794
Projects
None yet
Development

No branches or pull requests

2 participants