[Matroska-devel] EBML specification component for review - Introduction
dave at dericed.com
Thu Apr 30 06:35:45 CEST 2015
> On Apr 28, 2015, at 10:31 PM, Erik Piil <piil.erik at GMAIL.COM> wrote:
> This discussion relates to the "Introduction" portion of the earlier EBML RFC Draft for revision/incorporation into the final EBML specification.
> From the RFC Draft:
Although not in the spec, this language is very similar to what is in the ‘home page’ of the specification, see http://matroska-org.github.io/libebml/index.html <http://matroska-org.github.io/libebml/index.html>, excepting the BNF references. There are some places where I think the RFC draft language is clearer and some where I prefer the specification’s language.
> The Extensible Binary Markup Language EBML was designed to be a simplified binary version of XML for the purpose of storing and manipulating data in a hierarchical form with variable field lengths.
Nearly identical to what’s on http://matroska-org.github.io/libebml/index.html <http://matroska-org.github.io/libebml/index.html>. I prefer this version since it refers to the full name of EBML in the opening sentence.
> Specifically EBML was designed as the framework language for the video container format Matroska.
I prefer this to the spec’s: "EBML was originally created for the Matroska project."
> Some of the advantages of EBML are:
I prefer the RFC draft’s manner of starting with advantages and then going to disadvantages over the current way in the spec.
> - Possibility for compatibility between different versions of binary languages defined in EBML. A rare property of binary format that otherwise often needs careful consideration beforehand.
I feel like the meaning between this and the spec’s version has deviated a lot. Not sure which is preferable. The spec’s version is: "Upward compatibility when the format is updated. Something rare in binary formats, unless you have some unused space in the original format."
> - Unlimited size of data payload.
I prefer this to the spec version: "Unlimited size of binary data."
> - Can be both generated and read as a stream, without knowing the data size beforehand.
This doesn’t really exist in the spec. If true, I suggest we add it.
> - Often very space efficient, even compared to other binary representations of the same data.
I prefer this to the EBML spec version: "Very size efficient: only space required for a data is written (unless you specifically require more space for better updating later)."
> Some of the EBML disadvantages are:
> - No references can be made between EBML files, such as includes or inherits. Every EBML document is a self contained entity. The data stored in EBML may of course reference other resources.
> - No compositioning process to merge two or more EBML languages currently exists.
These don’t align well with the disadvantages listed in the spec. Perhaps they could be added, though it feels odd to detail the disadvantages of EBML so specifically.
> This document describes the EBML binary syntax, its semantic interpretation and the syntax of a textual document type definition format used to define the rules and constraints of an EBML language.
Not in spec, but I suggest including it. The current spec doesn’t have an equivalent objective line that I noticed.
> BNF is used throughout this document to augment the description and make it more formalized. It must however be noted that two different formats are described in this document, with two different BNFs. One for the binary format in chapter 2 and one for the document type definition in the rest of the document. To avoid confusion different token names has been chosen. The BNFs can be viewed in full in the appendices.
Same command about BNF/ABNF as prior thread on the ‘About this Document’ section.
Anyone mind if http://matroska-org.github.io/libebml/index.html <http://matroska-org.github.io/libebml/index.html> and http://matroska-org.github.io/libebml/specs.html <http://matroska-org.github.io/libebml/specs.html> are combined into one document?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel