Subject: [Cellar] EBML DocType 0

From: Steve Lhomme <[email-masked]>
Date: Sun, 26 Nov 2017 10:17:24 +0100

Hi,

We currently have a pending issue about how to define an experimental
version of a format.
https://github.com/Matroska-Org/ebml-specification/issues/157

We could either use DocType 0 to mark the version is in experimental
phase. Or we could add an element in the EBML Header that states the
status of the elements used.

I think the latter offers more flexibility. We could define that the
format in use in fully compliant with the version(s) set, that it adds
elements. In that case extra elements might be listed in the header.
That would be helpful to detect errors in the file since you know the
element IDs. But it might be complex. Since it would need the Path of
the element, its ID and the type. It would just mean we embed a DTD in
the EBML header (but just skipping the default/known elements).

IMO it is blocking the finalization of the EBML specifications, even
though it's an addition, because it will be key on how EBML formats
can evolve and still be compliant.

If we want to go the short way we might just add an element that we
know could be extended to a full DTD later. So a Master and a child
flag (standard/experimental/other?)

-- 
Steve Lhomme
Matroska association Chairman

---

From: Luca Barbato <[email-masked]>
Date: Sun, 26 Nov 2017 16:15:01 +0100

> flag (standard/experimental/other?)

Having the DTD would be nice to build programs to inspect the container 
or convert to the non-experimental version later.

Since experimental files is pretty much an exceptional path and we all 
want to not have broken files disseminated around the world, probably 
the additional overhead might help dissuading the usual early adopters.

lu

---

From: Ashley Blewer <[email-masked]>
Date: Sun, 26 Nov 2017 10:49:39 -0500

I like Dave Rice's suggestion in the above Github Issue, following FFV1's
pattern of version subtypes to set and express intention, which also leaves
the wording of the element broad.

On Sun, Nov 26, 2017 at 10:15 AM, Luca Barbato <[email-masked]>
wrote:

> Having the DTD would be nice to build programs to inspect the container or
> convert to the non-experimental version later.
>
> want to not have broken files disseminated around the world, probably the
> additional overhead might help dissuading the usual early adopters.
>
> lu
>
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

---

From: Jerome Martinez <[email-masked]>
Date: Sun, 26 Nov 2017 17:03:35 +0100

I am in favor to EBMLDocTypeVersionExperimental item, illegal for files 
complying to the standard.
I am not in favor to add a kind of "DTD" in the file, I don't see how to 
use it (if it is experimental, people know that the file is maybe not 
well supported, and the idea is not to spread such file)
IMO the idea of having a sub version in stable files as in FFV1 is not 
relevant here as FFV1 has no way to indicate that the stream is extended 
without this field, but we have a way to add more elements in EBML 
without breaking parsers (just by adding a new element value, old 
parsers just skip it).

---

From: Reto Kromer <[email-masked]>
Date: Sun, 26 Nov 2017 17:28:22 +0100

Luca Barbato wrote:

>Having the DTD would be nice to build programs to inspect the
>container or convert to the non-experimental version later.

I agree with Luca. Best regards, Reto

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 26 Nov 2017 17:43:20 +0100

> I agree with Luca. Best regards, Reto

I agree too that it's the cleanest approach. The problem is that it is
going be tricky to define such a DTD. Parsers will have to implement
an EBML Path parser and integrate that in various libraries. IMO that
should be for an EBML 2.

We could have a rough idea of how to do it though and just keep the
structure that tells a file may contain IDs outside of the known
scope. If anything just having an EBMLDoctypeDTD master element
present with nothing in it. Signaling that there might be unknown
elements in the file. (or rather something like
EBMLDoctypeDTD/ExtraElements).