[Matroska-devel] EBML specification component for review - Introduction

Dave Rice dave at dericed.com
Sat May 2 21:02:51 CEST 2015


Hi,

> On May 2, 2015, at 11:18 AM, Steve Lhomme <slhomme at matroska.org> wrote:
> 
> On Thu, Apr 30, 2015 at 6:35 AM, Dave Rice <dave at dericed.com <mailto:dave at dericed.com>> wrote:
> 
>> On Apr 28, 2015, at 10:31 PM, Erik Piil <piil.erik at GMAIL.COM <mailto: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:
>> 
>> Introduction
> 
> 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.
> 
> It's true.
>  
>> - 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?
>  
> Fine with me. Also the signature part should be marked as deprecated as discussed earlier. That should be feasible with a CSS style.
> 
> In a more general note. I think discussing document editing is very inefficient by email. I'd rather have a draft as a Markdown document on github that people can send pull requests to edit the document and discuss the changes from there. The website would reflect the "master/stable" of this Markdown document once in a while.
> 
> I prefer Markdown to HTML as it's much nicer to edit and github can interpret it nicely. The current specs don't have any editing features that are available in HTML and not in Markdown. 
> 
> Also as a source code file in git, it would be easier to track down how changes were made and the rationale behind each word/line/paragraph change.

I also favor markdown for writing the spec.

I would like to start breaking down the email discussion into a set to pull requests or issues. There’s been discussion on separating the specification from the code, whereas they are both together in the case of the libebml repo. I’m also considering that it may be bad form to actively work in the document shown at http://matroska-org.github.io/libebml/specs.html <http://matroska-org.github.io/libebml/specs.html>.

Before I start this do we have consensus on if the EBML spec work should move to its own repo (whereas it now resides in the gh-pages branch of the libebml report) or if it should stay there. In the latter case, we need a branch of gh_pages to start the html to markdown work.
Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20150502/5c5b2b46/attachment-0001.html>


More information about the Matroska-devel mailing list