[Cellar] EBML Extensions

[Steve Lhomme <[e-mail]>]

Following the discussion on RAWcooked elements we need a way to define
how to create extensions to a DocType that are not meant to be merged
in the main DocType specifications.

The XML Schema we use is already quite good for external files as we
can define the exact path an element can be found, independently of
the main specs. We even have fields in the header to tell which
DocType and which version of the DocType it applies to.

What we don't have is these information when reading an EBML file. We
know the DocType and the version but we don't know of any extensions
that are also valid in this file.

If we had a DTD/Schema embedded in every EBML file that would be where
we put these data. But we don't. And there may be simpler way to do
it, in the same philosophy as EBML/Matroska: only write information
that's not obvious.

We can take the RAWcooked elements as an example for what we need:
https://github.com/Matroska-Org/matroska-specification/pull/223/files

This should be a separate XML file that has the same DocType and
version as the current Matroska one.
https://github.com/Matroska-Org/matroska-specification/blob/master/ebml_matroska.xml
We may also include a human readable name for the extension like
extension="RAWcooked".

The 3 added elements and that's it. That would be enough for the
extension definition.

In the file/stream we should tell if this extension is used, when it's
used. The logical way to do that is to put this information in the
EBML header. We will also need the IDs, the path where they belong and
at least if it's a master element or not (to allow children elements).
The path actually contains a lot of information like the maximum of
occurrences or if it's a recursive element and even how the recursion
works.

The goal is not to interpret the values but only to tell what is valid
and not valid we may not need to know the exact type of the value and
the allowed ranges. But that could be added as well.

The path would probably be in a binary format. Especially as the
elements name are not known.

So in the case of RAWcooked we would have something like that stored
in the EBML header:
EBML
  EBMLExtensions
      EBMLExtensions
        ExtensionName: RAWcooked
        ExtensionElement
          ExtensionElementPath: 0*1(\0x18538067\0x1F43B675\0xA0\0x207262)
          ExtensionElementHasChildren: 0 (may be the type otherwise)
        ExtensionElement
          ExtensionElementPath: 0*(\0x18538067\0x207273)
          ExtensionElementHasChildren: 0
        ExtensionElement
          ExtensionElementPath: 0*1(\0x18538067\0x1654AE6B\0xAE\0x207274)
          ExtensionElementHasChildren: 0


We could add extra elements like a URL to know more about that
extension, a human readable name for each element, etc. The URL may
also replace the ExtensionName.

The separators between IDs may be kept as we need a way to wrap things
in this way: 1*(\Segment\Chapters\EditionEntry(1*(\ChapterAtom)))

Opinions ?

Given the state of EBML it may be for a subsequent version of EBML so
we don't delay the current one further.

-- 
Steve Lhomme
Matroska association Chairman