Subject: [Cellar] EBML spec questions

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Sun, 23 Oct 2016 17:39:39 +0200

Hi,

I have a few questions regarding the EBML specs.

"Date Element"

What happens after "2293-04-11T11:47:16.854775807 UTC"?

Is there a way to use the date type after that date for dates after the
date? E.g. File modification date 2294-02-01T10:24:00.012345678 UTC?

If that is not the case, then why can't it be the case? (I do understand
the limitation due to the maximum of the octets, but not why it has to
be a signed integer, whereas an unsigned integer would allow a larger
range, even though only positive.)

"EBML Schema"

"The DocType value for an EBML Document Type SHOULD be unique and
persistent."

What would be a reason for violation that SHOULD? Wouldn't that be
better a MUST?

Best Regards,
Sebastian

---

From: Dave Rice <[email-masked]>
Date: Sun, 23 Oct 2016 15:43:40 -0400

> On Oct 23, 2016, at 11:39 AM, Sebastian G. <bastik> <[email-masked]> wrote:
> 
> Hi,
> 

IIUC this is not possible with a Date Element. Feasibly a future version of EBML could adjust the Date Element definition to include longer byte lengths. Hopefully someone can do this within the next 277 years.

> What would be a reason for violation that SHOULD? Wouldn't that be

Perhaps it can be MUST. When writing I was thinking that we should avoid some Matroska writers using "matroska" and others using "Matroska" and considering it as the same EBML Document Type. Likewise someone creating a different EBML Document Type should avoid also calling that as "matroska".

In XML the equivalent of DocType is the XML Namespace [1], is defined like (underlining mine): "The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). Uniform Resource Names [RFC2141] is an example of a syntax that is designed with these goals in mind. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals."

Dave Rice

[1]: https://www.w3.org/TR/REC-xml-names/#ns-decl

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Mon, 24 Oct 2016 20:02:13 +0200

> IIUC this is not possible with a Date Element. Feasibly a future version of EBML could adjust the Date Element definition to include longer byte lengths. Hopefully someone can do this within the ne…

I would hope that it is possible to do something about it rather sooner
than later.

It is a Date Element that stores its value in a nanosecond
representation. At least that is how I understand it.

There could be a Time Element and a Date Element, where the Date Element
holds only days that are positive or negative from the start date and
the Time Element holds the time in nanoseconds or even below that to be
able to be even more precise.

>> What would be a reason for violation that SHOULD? Wouldn't that be

(What would be a reason for violating that SHOULD?, should have been my
question.)

> Perhaps it can be MUST. When writing I was thinking that we should avoid some Matroska writers using "matroska" and others using "Matroska" and considering it as the same EBML Document Type. Likewi…

Well, using different cases did not occur to me. To me it appears that a
parser should be able to read 'matroska' and "Matroska' without any
issue even though that for consistency only one version SHOULD be
written. My concern was that no one could use the 'matroska' DocType if
that is a Schema that already exists and does not comply with the
existing Schema.

One could keep it like it is while adding something like follows:

"The DocType value for an EBML Document Type SHOULD be unique and
persistent. One MUST NOT use an EBML Document Type that is already in
definitive use by an already defined Schema, when one does not refer to
such a Schema."

Changes in wording are welcome.

Best Regards,
Sebastian

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 30 Oct 2016 10:35:14 +0100

> range, even though only positive.)

We want to be able to add dates to things that were recorded before
2001. Which is currently more common that 2294.

However far the year 2294, people doing projections far in the future
might have use for larger dates. But they can always use a binary
format with a larger range. Their DocType will tell them how to
interpret the data.

> What would be a reason for violation that SHOULD? Wouldn't that be

IMO we cannot ensure/guarantee the uniqueness globally. So it's a
requirement that should be done as best as possible but can't be
verified.

> Best Regards,
> Sebastian
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Sun, 30 Oct 2016 19:10:24 +0100

> 2001. Which is currently more common that 2294.

Indeed, there is a need to express dates before a certain date. However,
that would not have required to be precise down to the nanosecond. Well
for a duration nanoseconds are desirable.

> format with a larger range. Their DocType will tell them how to

Wouldn't it be better to have something more universal and future-proof?

A 'Year Element' could be defined to start at year zero (either
something like the approximated birth of Christ or the approximated
ignition of our sun) and go minus or plus the desired amount of years.

A 'Month Element', possibly a child of the 'Year', could hold values
starting at 0 and only going up. Currently there are only twelve months,
but that used to be different. But yes, a range from 0-11 (12) would be
enough to cover the current use of a month. (2^4 for binary)

A 'Day Element', possibly a child of 'Month', could hold values starting
at 0 and only going up. This would be covered by a range from 0-30 (31).
(2^5 for binary)

And then maybe "just" a time element or even that being split up into
its various parts. All of that should give the ability to represent any
date, precisely down to the nanosecond or even more precise if defined

To me it appears structured and that it would be possible to use it for
ordering files chronologically.

> requirement that should be done as best as possible but can't be

As you can see later in that thread I agreed to what Dave said and I
hereby agree what you say. As I see it you have no way to enforce said
uniqueness.

Best Regards,
Sebastian