Subject: [Cellar] Fwd: Re: EBML spec questions

From: "Sebastian G. <bastik>" <[email-masked]>
Date: Mon, 31 Oct 2016 19:21:11 +0100

I assume that it was not intended to have this conversation off-list, so
I forward it to the list.

Basically there is no reason for me to care that much. Especially if
what you say is true. Surely you have more knowledge about the subject.

(For scientific experiments you can go lower, like femtoseconds for
pulsing lasers that correct vision.)

Indeed comparing two single values is much easier than comparing a set
of values. Also true that the set becomes rather pointless if it would
not be complete and the more fields there are the higher the risk of the
set being broken.

I don't think that it will be too crazy some time in the future,
comparing what technological advances have been made so far. (Beside
physical limitations, that can't be overcome.)

With that said, I think this thread is done.

Best Regards,
Sebastian

-------- Fwd --------
Subject: Re: [Cellar] EBML spec questions
Date: Sun, 30 Oct 2016 19:21:20 +0100
From: Steve Lhomme <[email-masked]>
To: Sebastian G. <bastik> <[email-masked]>

Le 30 oct. 2016 19:10, "Sebastian G. &lt;bastik&gt;" <
[email-masked]> a écrit :
>
> 30.10.2016, 10:35 Steve Lhomme:
> > 2016-10-23 17:39 GMT+02:00 Sebastian G. <bastik>
> > <[email-masked]>:
> >> 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.)
> >
> > We want to be able to add dates to things that were recorded before
> > 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.

The nanosecond was so that scientific experiments can have enough
precision.

Many fields as you propose is a pain to handle (think calendar) tricky to
compare and less resilient.

> > 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.
>
> Wouldn't it be better to have something more universal and future-proof?

The easy way for that would be to allow 128 bits dates. In 20 years maybe
it won't seem so crazy.

> 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.
>
> >> "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?
> >
> > 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.
>
> 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
> >>
>
> Best Regards,
> Sebastian
>