[Matroska-devel] Re: EBML

[Steve Lhomme]

Martin Nilsson wrote:
> I did an HTML version of the revesion before 2.4.0, but it was so 
> incredibly time consuming that I really didn't want to go through it 
> again. I did however look into building an XML format for RFC-like 
> texts, envisioning one XSLT to make the text version and one to make the 
> HTML version. As with many projects I didn't come too far, mostly 
> because no one else was interested.

You might like to have a look at the DocBook file format. You can 
generate your doc in many formats then (HTML, PDF, text, etc). We 
started the Matroska specs in this format a while back, but we stopped 
to spend more time actually writing things (there is a learning curve 
but it's worth it).

For the rest, I'll check the problems tonight.

> Should really SignatureSlot be part of the EBML core standard?

Probably not. Lots of basic formats that could use EBML would probably 
not need a complicated/versatile signature system support. It can be 
optional at the "EBML-children" level (like Matroska).

> Isn't CRC-32 better implemented as a container element? Then the decoder 
> will know when it must calculate CRC-32 and the start and end is very 
> obvious. I also think the requirement for a CRC-32 element in every 
> level 1 elements should be dropped. It isn't even met in all files I've 
> found to experiment with.

I think the CRC-32 is OK because it gives a simple way to every EBML 
user to have error detection at almost no cost.
The level 1 requirement is for Matroska (and a guideline, not a formal 
rule) not for EBML.

> Should we drop the string type? It is a complete subset of the utf8 type 
> and since I've defined ranges on utf8 strings to limit the range of 
> every byte, you can still define an element to have the same practical 
> meaning.

It's a subset with more restrictions. These restrictions *are* sometimes 
needed, like when you have a URL for example. So I think it should be 
kept. Plus it is very common in the computer world...