EBML, Extensible Binary Meta-Language (o Extensible Binary Meta Language) es un nuevo lenguage de marcado de información conceptualmente semejante al XML pero diseñado para ser más compacto y codificar datos binarios.
Muchos lo ocnsideran una variante del concepto de «reinventar la rueda» puesto que esta necesidad está tradicionalmente cubierta con la notación ASN.1 Abstract Syntax Notation One (notación sintáctica abstracta 1).
Sin embargo es interesante conocerla, por lo que se incluye seguidamente un borrador de la especcificación:
RFC v1.0
Draft M. Nilsson
Document: ebml-1.0.txt 15th March 2004
Extensible Binary Markup Language
Copyright
Copyright (C) Martin Nilsson 2004. All rights reserved.
Abstract
The extensible binary markup language, EBML, is a binary language
for storing hierarchical, typed in data in a compact, yet easily
parsed format.
About this document
This document is currently in its draft stage and is subject to
changes. The contents should not be relied upon for
implementational purposes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
The definitions in this document uses ABNF [ABNF]. Note that string
terminals are case insensitive in ABNF. The interpretation of
binary values has been slightly altered so that every bit must be
explicitly printed, e.g. %b0 is one zero bit while %b000 represents
three zero bits. The following (re)definitions are used throughout
this document.
BIT = %b1 / %b0
BYTE = OCTET
WSP = SP / HTAB / CR / LF
1. Introduction
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. Specifically EBML was designed as the framework language
for the video container format Matroska. Some of the advantages of
EBML are:
- 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.
- Unlimited size of data payload.
- Can be both generated and read as a stream, without knowing the
data size beforehand.
- Often very space efficient, even compared to other binary
representations of the same data.
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.
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. 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.
2. Structure
Syntactically an EBML document is a list of EBML elements. Each
element has three parts; an element ID, a size descriptor and the
element data payload. The element data payload is then either data,
implicitly typed by the element ID, or a list of EBML elements.
EBML = *ELEMENT
ELEMENT = ELEMENT_ID SIZE DATA
DATA = VALUE / *ELEMENT
ELEMENT_ID = VINT
SIZE = VINT
EBML uses big endian/network order byte order, i.e. most
significant bit first. All of the tokens above are byte aligned.
2.1. Variable size integer
For both element ID and size descriptor EBML uses a variable size
integer, coded according to a schema similar to that of UTF-8
[UTF-8] encoding. The variable size integer begins with zero or
more zero bits to define the width of the integer. Zero zeroes
means a width of one byte, one zero a width of two bytes etc. The
zeroes are followed by a marker of one set bit and then follows the
actual integer data. The integer data consists of alignment data
and tail data. The alignment data together with the width
descriptor and the marker makes up one ore more complete bytes. The
tail data is as many bytes as there were zeroes in the width
descriptor, i.e. width-1.
VINT = VINT_WIDTH VINT_MARKER VINT_DATA
VINT_WIDTH = *%b0
VINT_MARKER = %b1
VINT_DATA = VINT_ALIGNMENT VINT_TAIL
VINT_ALIGNMENT = *BIT
VINT_TAIL = *BYTE
An alternate way of expressing this is the following definition,
where the width is the number of levels of expansion.
VINT = ( %b0 VINT 7BIT ) / ( %b1 7BIT )
Some examples of the encoding of integers of width 1 to 4. The x:es
represent bits where the actual integer value would be stored.
Width Size Representation
1 2^7 1xxx xxxx
2 2^14 01xx xxxx xxxx xxxx
3 2^21 001x xxxx xxxx xxxx xxxx xxxx
4 2^28 0001 xxxx xxxx xxxx xxxx xxxx xxxx xxxx
2.2. Element ID
The EBML element ID is encoded as a variable size integer with, by
default, widths up to 4. Another maximum width value can be set by
setting another value to EBMLMaxIDWidth in the EBML header. See
section 5.1. IDs are always encoded in their shortest form, e.g. 1
is always encoded as 0x81 and never as 0x4001. This limits the
number of IDs in every class with the number of IDs in the previous
classes. Furthermore, values with all data bits set to 1 and all
data bits set to 0 are reserved, hence the effective number of IDs
are as follows for different widths. Note that the shortest
encoding form for 127 is 0x407f since 0x7f is reserved.
Class Width Number of IDs
A 1 2^7-2 = 126
B 2 2^14-2^7 = 16 256
C 3 2^21-2^14 = 2 080 768
D 4 2^28-2^21 = 266 338 304
2.3. Element data size
The EBML element data size is encoded as a variable size integer
with, by default, widths up to 8. Another maximum width value can
be set by setting another value to EBMLMaxSizeWidth in the EBML
header. See section 5.1. There is a range overlap between all
different widths, so that 1 encoded with width 1 is semantically
equal to 1 encoded with width 8. This allows for the element data
to shrink without having to shrink the width of the size
descriptor.
Values with all data bits set to 1 means size unknown, which allows
for dynamically generated EBML streams where the final size isn't
known beforehand. The element with unknown size MUST be an element
with an element list as data payload. The end of the element list is
determined by the ID of the element. When an element that isn't a
sub-element of the element with unknown size arrives, the element
list is ended.
Since the highest value is used for unknown size the effective
maximum data size is 2^56-2, using variable size integer width 8.
2.4. Values
Besides having an element list as data payload an element can have
its data typed with any of seven predefined data types. The actual
type information isn't stored in EBML but is inferred from the
document type definition through the element ID. The defined data
types are signed integer, unsigned integer, float, ASCII string,
UTF-8 string, date and binary data.
VALUE = INT / UINT / FLOAT / STRING / DATE / BINARY
INT = *8BYTE
Signed integer, represented in two's complement notation, sizes
from 0-8 bytes. A zero byte integer represents the integer value 0.
UINT = *8BYTE
Unsigned integer, sizes from 0-8 bytes. A zero byte integer
represents the integer value 0.
FLOAT = *1( 4BYTE / 8BYTE / 10BYTE )
IEEE float [FLOAT], sizes 0, 4, 8 or 10 bytes. A zero byte float
represents the float value 0.0.
PADDING = %x00
STRING = *BYTE *PADDING
UTF-8 [UTF-8] encoded Unicode [UNICODE] string. A string MAY be
zero padded at the end. Note that a string can be of zero length.
DATE = 8BYTE
Signed, 64-bit (8 byte) integer describing the distance in
nanoseconds to the beginning of the millennium (2001-01-01 00:00:00
UTC).
BINARY = *BYTE
Binary data, i.e. not interpreted at the EBML level.
3. Semantic interpretation
Every element has several properties defined in the document type
definition, which are needed for the correct syntactical and
semantic handling of the information. These properties are name,
parent, ID, cardinality, value restrictions, default value, value
type and child order.
To syntactically parse EBML data we need to know the element value
types, and to semantically interpret that data we also need to know
the element IDs and element names. Elements can have a default
value, so for the final presentation of the parsed EBML data
elements that wasn't stored in the data may show up. Finally
elements may have restrictions in terms of which parent or parents
they may have, the number of times they may occur in the EBML data,
their order in the document and various additional restrictions of
their data payload.
3.1. Name property
The name is the symbolic identifier of an element and has a 1:1
mapping to the element ID. Only alphanumeric characters and
underscores may be used for the name. It may not start with a
number. Names are treated case insensitive, i.e. "Name" is the same
identifier as "name".
NAME = [A-Za-z_] 1*[A-Za-z_0-9]
3.2. Value type property
There is no way of knowing whether or not to look for sub elements
with only the information presented in the EBML data. Hence the
element value type is the most important information in the EBML
DTD. In addition to the value types defined in section 2.4 an
element can also be of the type "container", which simply means
that its content is more elements.
3.3. ID property
Every element must have an ID associated, as defined in section
2.2. These IDs are expressed in the hexadecimal representation of
their encoded form, e.g. 1a45dfa3.
ID = 1*( 2HEXDIG )
3.4. Default value property
Every non-container MAY be assigned a default value. If so, its
value will be added to the interpretation of the EBML data if no
element with another value exists in the data.
As an example, consider this EBML DTD:
Weight := 4101 {
WeightValue := 41a1 uint;
WeightUnit := 41a2 string [ def:"kilogram" ];
}
If the Weight element only contains the WeightValue element, the
WeightUnit element with value "kilogram" will be added when the
information is semantically processed. A WeightUnit element with
another value would of course override the default.
The default value can also be a symbol referring back to a
previously seen symbol. If however no such symbol has been seen,
i.e. it has not been encoded into the EBML data and has no default
value, the element will not be added as a child on the semantic
level.
Weight := 4101 {
WeightValue := 41a1 uint;
WeightUnit := 41a2 string [ def:WeightUnit ];
}
In this example all Weight elements will use the same weight unit
as the previous one. To ensure that the first one has a value its
cardinality should be set to "1". See section 3.6.
DEFAULT = INT_DEF / UINT_DEF / FLOAT_DEF / STRING_DEF /
DATE_DEF / BINARY_DEF / NAME
DATE_VALUE = *1DIGIT 2DIGIT 2DIGIT
*1(%x54 2DIGIT ":" 2DIGIT ":" 2DIGIT
*1( "." *1DIGIT ))
INT_DEF = *1"-" 1*DIGIT
UINT_DEF = 1*DIGIT
FLOAT_DEF = INT "." 1*DIGIT *1( "e" *1( "+"/"-" ) 1*DIGIT )
DATE_DEF = INT_DEF / DATE_VALUE
STRING_DEF = ("0x" 1*( 2HEXDIG )) / ( %x22 *(%x20-7e) %x22 )
BINARY_DEF = STRING_DEF
The date default value is either described as the integer in its
encoded form or in the ISO short format; YYYYMMDD followed by the
string literal T, the time as HH:MM:DD and finally and optionally
the fractions as .F with an optional numbers of F for
precision. Some examples:
ExampleInt := c0 int [ def:-114; ]
ExampleUInt := c1 uint [ def:0; ]
ExampleFloat := c2 float [ def:6.022E23 ]
ExampleDate := c3 date [ def:20011224T15:00:03.21; ]
ExampleBinary := c5 binary [ def:0x4944337632; ]
ExampleString := c6 string [ def:"Sweden"; ]
3.5. Parent property
To place the elements in a hierarchical structure we need
relational information about the elements. In the EBML DTD this is
expressed as the possible parents an element may have. This can be
expressed in two ways: an explicit list of allowed parents or a
generic definition of allowed insertion depth.
PARENTS = NAME / ( NAME "," PARENTS )
LEVEL = 1*DIGIT *1( ".." *DIGIT )
An element with neither parents nor level defined is assumed to
exist on the top level in the EBML document. An element can not
have both a parent and a level property.
The following example contains two elements, Envelope and
Letter. The Letter must, if it exists in the document, be a child
of Envelope and Envelop must, if it exists in the document, reside
at the top level.
Envelope := a0 container;
Letter := b0 string [ parent:Envelope; ]
The following example expresses the exact same relationships, but
in an abbreviated syntax.
Envelope := a0 container {
Letter := b0 string;
}
The following example shows that the abbreviated syntax can't be
used to solve all relations. Here the Letter element can be a child
in both the Envelope element and the Trashcan element. The explicit
parent information is merged with the one expressed with the
abbreviated syntax.
Envelope := a0 container {
Letter := b0 string [ parent:Trashcan; ];
}
Trashcan := a1 container;
The following example demonstrates the usage of level instead of
parent. The element Void may occur at any place in the EBML
document.
Void := ec binary [ level:1..; card:*; ]
This is an example similar to the one above, but using containers
instead. The children of the parent to the SHA1 element may be
pushed down to the level where "%children;" is, i.e. if used with
the first Letter-Envelope example the Envelope may contain an SHA1
element which may contain an SHA1Content element which may contain
a Letter element. A container element with a level property MUST
NOT use undefined size as described in section 2.3, since then the
end of the element can not be determined in all cases.
SHA1 := 190babe5 container [ level:1..; card:*; ] {
SHA1Content := 20110f container {
%children;
}
SHA1Hash := 20110e binary;
}
3.6. Cardinality property
The cardinality of an element declares how many times an element
may occur in its current scope. By default an element may only
occur at most once in a scope, e.g. if the element Weight has been
defined as a child to Brick, no more than one Weight element can be
used in every Brick element. The cardinality can however be altered
from the default to any of the following. Note that this affects
all scopes that the element can be inserted into.
Symbol Interpretation
* Zero or more occurrences.
? Zero or one occurrence (default).
1 Exactly one occurrence.
+ One or more occurrences.
CARDINALITY = "*" / "?" / "1" / "+"
3.7. Child order property
The child order property only applies to container elements. It
simply declares if the children of the element must appear in the
order they are defined in or not. By default this restriction is
imposed on all children to all elements. The advantage of ordered
elements in combination with default values is that the EBML
decoder will know immediately once an element is skipped and can
output the appropriate default value instead.
YES = "yes" / "1"
NO = "no" / "0"
ORDERED = YES / NO
3.8. Value restriction properties
Every element may impose additional constraints upon its
value. These constraints are only used to validate data during
encoding and makes no difference for the decoding or interpretation
of the encoded data. The available constraints and syntax differs
between different types of elements.
3.8.1. Range
The range of an element value determines the allowed values that
the element value may have. The range is expressed as one or more
specific values or spans of allowed values, with the exception of
floats and dates where only spans are allowed.
RANGE_LIST = RANGE_ITEM / ( RANGE_ITEM S "," S RANGE_LIST )
RANGE_ITEM = INT_RANGE / UINT_RANGE / FLOAT_RANGE /
STRING_RANGE / DATE_RANGE / BINARY_RANGE
For integers the range is a list of values and open or closed
ranges, e.g. "0,1", "1..5" and "..-1,1..". The final allowed range
is a union of all listed ranges. If a value matches any of the
listed ranges it is considered valid.
INT_RANGE = INT_DEF / ( INT_DEF ".." ) / ( ".." INT_DEF ) /
( INT_DEF ".." INT_DEF )
Unsigned integers is similar, but can not have its range open to
the left.
UINT_RANGE = UINT_DEF *1( ".." UINT_DEF )
Floats can have both inclusive and exclusive end points of its
ranges.
FLOAT_RANGE = ( ("<" / "<="/ ">" / ">=") FLOAT_DEF ) /
( FLOAT_DEF "<"/"<=" ".." "<"/"<=" FLOAT_DEF )
Date ranges has the same syntax and semantics as integer ranges,
except that the actual date can be described either as an integer
or in ISO short format.
DATE_RANGE = ( DATE_DEF ".." ) / ( ".." DATE_DEF ) /
( DATE_DEF ".." DATE_DEF )
String and binary ranges limits the range for each character/byte
in the string. Note that in the string case this is for the
unencoded unicode data, i.e. the possible range is larger than
0-255, which is the bounding range for binary data.
STRING_RANGE = UINT_RANGE
BINARY_RANGE = UINT_RANGE
3.8.2. Size
The size of an element value is simply the number of bytes it
occupies in its encoded form. That means that the size of a string
element value need not be the same as the string length.
SIZE_LIST = UINT_RANGE / ( UINT_RANGE S "," S SIZE_LIST )
4. Document Type Definition
The EBML document type definition, EDTD, is an ASCII based language
that allows for the constraints and relations described in chapter
3 to be described in a way that is both human and computer
readable. Syntactically it consists of blocks, not unlike most
programming languages, which contains definitions/declarations
similar to BNF. The format is largely whitespace insensitive, case
insensitive and supports both C-style (LCOMMENT) and C++-style
(BCOMMENT) comments. The BNF lines in this chapter is somewhat
simplified for readability compared to the complete BNF in Appendix
B.
COMMENT = LCOMMENT / BCOMMENT
S = *WSP / ( *WSP COMMENT *WSP ) ; Optional white spaces
On the top level of the EDTD only three different blocks are
currently defined, header declarations, type definitions and
element definitions.
DTD = *( S / HBLOCK / TBLOCK / EBLOCK )
4.1. Header declarations
The meaning of the header declaration is to declare what values
should be put into the elements of the header, should they differ
from the default values. The header declaration block is written as
"declare header" followed by curly brackets that encloses the block
of statements. The actual statements are very straightforward, the
element name followed by ":=" followed by the value, as described
in section 3.4, followed by ";". There MUST only be one header
declaration block in a DTD.
HBLOCK = "declare" WSP "header" S "{" *(S / STATEMENT) "}"
STATEMENT = NAME S ":=" S DEFS S ";"
Since the DocType element has no default value it MUST be declared
in the EDTD. It is RECOMMENDED that the EBMLVersion is also
declared. Such a declaration could look like this:
declare header {
DocType := "xhtml";
EBMLVersion := 1;
}
4.2. Type definitions
Type definitions is a way to create types with more mnemonic names,
making the DTD both smaller and easier to read. The type
definitions block is written as "define types" followed by a block
of statements enclosed in curly brackets. Each statement is a type
name followed by ":=" followed by the type on which this type
should be based on, optionally followed by a list of properties,
enclosed in angle brackets. The type names follows the same rules
as element names, but lives in another namespace, i.e. there may be
an element with the same name as a type.
TBLOCK = "define" S WSP "types" S "{" *(S / DTYPE) "}"
DTYPE = NAME S ":=" S TYPE S (PROPERTIES S *1";")/";"
The base type may be another defined type, as long as the
definitions are made in order, as shown in the following example.
define types {
digits := int;
number := digits;
}
The type definition then both allows for types as described in
section 2.4 and NAME, which refers to types previously defined in
the document.
TYPE = VTYPE / CTYPE
VTYPE = "int" / "uint" / "float" / "string" / "date" /
"binary" / NAME
CTYPE = "conainer" / NAME
If the type definition has no list of properties, the statement is
ended with ";". If the it has a property list, ending the statement
with ";" is optional.
PROPERTIES = "[" S 1*PROPERTY S "]"
PROPERTY = PROP_NAME S ":" S PROP_VALUE S ";"
Some examples:
crc32 := binary [ size:4; ]
sha1 := binary [ size:20; ]
bool := uint [ range:0..1; ]
us_printable := binary [ range:32..126; ]
4.2. Element definitions
The element definitions is the real purpose of the DTD. The element
definitions block is written as "define elements" followed by a
block of statements enclosed in curly brackets. Each statement can
be either a simple statement similar to the type definition
statements, or a block statement, containing more statements.
EBLOCK = "define" WSP "elements" S "{" *(S / ELEMENT) "}"
DELEMENT = VELEMENT / CELEMENT / "%children;"
The simple statements are typically used for value elements and
consists of a name followed by ":=", id, type and optionally
properties.
VELEMENT = NAME S ":=" S ID WSP S TYPE S (PROPERTIES S *1";")/";"
The block version of the element statements are only used to
express parent-children relations. See section 3.5.
CELEMENT = NAME S ":=" S ID WSP S "container" S *1PROPERTIES S
("{" *DELEMENT "}")/";"
5. EBML standard elements
EBML defines a small set of elements that can be used in any EBML
application. An EBML document MUST begin with an EBML header
consisting of the EBML element. Generally speaking it would be
possible to define default values to all elements in the EBML
element in the document type definition for an application, and
thus being able to represent the entire header without have a
single byte written. However, in order to be able to identify EBML
documents between applications it is REQUIRED that all EBML
elements whose values differs from the standard defaults in this
document, are written in EBML data. In practice that means that at
least the DocType is always stored in all EBML documents.
5.1. EBML
The EBML element is a container for the EBML header.
EBML := 1a45dfa3 container [ card:+; ]
5.1.1. EBMLVersion
EBMLVersion is the version of EBML to which the document conforms
to.
EBMLVersion := 4286 uint [ def:1; parent:EBML; ]
5.1.2. EBMLReadVersion
The minimum EBML version a parser has to support in order to read
the document.
EBMLReadVersion := 42f7 uint [ def:1; parent:EBML; ]
5.1.3. EBMLMaxIDWidth
The maximum width of the IDs used in this document. It is
RECOMMENDED to not have wider IDs than 4. EBMLMaxIDWidth may be
larger than any actual width used in the document.
EBMLMaxIDWidth := 42f2 uint [ def:4; parent:EBML; ]
5.1.4. EBMLMaxSizeWidth
The maximum width of the size descriptors used in this document. It
is RECOMMENDED to not have wider size descriptors than 8.
EBMLMaxSizeWidth may be larger than any actual width used in the
document.
EBMLMaxSizeWidth := 42f3 uint [ def:8; parent:EBML; ]
5.1.5. DocType
An ASCII string that identifies the type of the document.
DocType := 4282 binary [ range:32..126; parent:EBML; ]
5.1.6. DocTypeVersion
DocTypeVersion is the version of document type to which the
document conforms to.
DocTypeVersion := 4287 uint [ def:1; parent:EBML; ]
5.1.7. DocTypeReadVersion
The minimum DocType version an interpreter has to support in order
to read the document.
DocTypeReadVersion := 4285 uint [ def:1; parent:EBML; ]
5.2. CRC32
The CRC32 container can be placed around any EBML element or
elements. The value stored in CRC32Value is the result of the
CRC-32 [CRC32] checksum performed on the other child elements.
CRC32 := c3 container [ level:1..; card:*; ] {
%children;
CRC32Value := 42fe binary [ size:4; ]
}
5.3. Void
The void element can be used as padding to prepare for more data,
or to fill space when data has been removed. It should simply be
ignored when the document is interpreted.
Void := ec binary [ level:1..; card:*; ]
6. References
[ABNF] D. Crocker, P. Overell, 'Augmented BNF for Syntax
Specifications: ABNF', RFC 2234, November 1997.
<url:ftp://ftp.isi.edu/in-notes/rfc2234.txt>
[CRC32] International Organization for Standardization, 'ISO
Information Processing Systems - Data Communication High-Level Data
Link Control Procedure - Frame Structure", IS 3309, October 1984,
3rd Edition.
[FLOAT] Institute of Electrical and Electronics Engineers, 'IEEE
Standard for Binary Floating-Point Arithmetic', ANSI/IEEE Standard
754-1985, August 1985.
[RFC2119] S. Bradner, 'Key words for use in RFCs to Indicate
Requirement Levels', RFC 2119, March 1997.
<url:ftp://ftp.isi.edu/in-notes/rfc2119.txt>
[UNICODE] International Organization for Standardization,
'Universal Multiple-Octet Coded Character Set (UCS), Part 1:
Architecture and Basic Multilingual Plane', ISO/IEC 10646-1:1993.
<url:http://www.unicode.org>
[UTF-8] F. Yergeau, 'UTF-8, a transformation format of ISO 10646',
RFC 3629, November 2003.
<url:ftp://ftp.isi.edu/in-notes/rfc3629.txt>
Appendix A. EBML BNF
EBML = *ELEMENT
ELEMENT = ELEMENT_ID SIZE DATA
DATA = VALUE / *ELEMENT
VINT = ( %b0 VINT 7BIT ) / ( %b1 7BIT )
; A more annotated but less correct definition of VINT
;
; VINT = VINT_WIDTH VINT_MARKER VINT_DATA
; VINT_WIDTH = *%b0
; VINT_MARKER = %b1
; VINT_DATA = VINT_ALIGNMENT VINT_TAIL
; VINT_ALIGNMENT = *BIT
; VINT_TAIL = *BYTE
ELEMENT_ID = VINT
SIZE = VINT
VALUE = INT / UINT / FLOAT / STRING / DATE / BINARY
PADDING = %x00
INT = *8BYTE
UINT = *8BYTE
FLOAT = *1( 4BYTE / 8BYTE / 10BYTE )
STRING = *BYTE *PADDING
DATE = 8BYTE
BINARY = *BYTE
Appendix B. EBML DTD BNF
; NOTE: This BNF is not correct in that it allows for more freedom
; than what is described in the text. That is because a 100%
; correct BNF would be almost unreadable. To be correct CELEMENT
; would be split into one ELEMENT token for every value type, and
; then each and every one of them would have their own PROPERTIES
; definition which points out only the DEF and RANGE for that value
; type. Some other shortcuts are noted in comments.
LCOMMENT = "//" *BYTE (CR / LF) ; *BYTE is string without CR/LF
BCOMMENT = "/*" *BYTE "*/" ; *BYTE is string without "*/"
COMMENT = LCOMMENT / BCOMMENT ; Line comment / Block comment
S = *WSP / ( *WSP COMMENT *WSP ) ; Optional white spaces
DTD = *( S / HBLOCK / TBLOCK / EBLOCK )
HBLOCK = "declare" S WSP "header" S "{" *(S / STATEMENT) "}"
EBLOCK = "define" S WSP "elements" S "{" *(S / DELEMENT) "}"
TBLOCK = "define" S WSP "types" S "{" *(S / DTYPE) "}"
DELEMENT = VELEMENT / CELEMENT / "%children;"
VELEMENT = NAME S ":=" S ID WSP S TYPE S (PROPERTIES S *1";")/";"
CELEMENT = NAME S ":=" S ID WSP S "container" S *1PROPERTIES S
("{" *DELEMENT "}")/";"
NAME = [A-Za-z_] 1*[A-Za-z_0-9]
ID = 1*( 2HEXDIG )
TYPE = VTYPE / CTYPE
VTYPE = "int" / "uint" / "float" / "string" / "date" /
"binary" / NAME
CTYPE = "conainer" / NAME
PROPERTIES = "[" S 1*PROPERTY S "]"
PROPERTY = PARENT / LEVEL / CARD / DEF / RANGE / SIZE
PARENT = "parent" S ":" S PARENTS S ";"
PARENTS = NAME / ( NAME S "," S PARENTS )
LEVEL = "level" S ":" S 1*DIGIT *(".." *DIGIT) S ";"
CARD = "card" S ":" S ( "*" / "?" / "1" / "+" ) S ";"
ORDERED = "ordered" S ":" S ( YES / NO ) S ";"
YES = "yes" / "1"
NO = "no" / "0"
DEF = "def" S ":" S DEFS S ";"
DEFS = ( INT_DEF / UINT_DEF / FLOAT_DEF / STRING_DEF /
DATE_DEF / BINARY_DEF / NAME )
RANGE = "range" S ":" S RANGE_LIST S ";"
RANGE_LIST = RANGE_ITEM / ( RANGE_ITEM S "," S RANGE_LIST )
RANGE_ITEM = INT_RANGE / UINT_RANGE / FLOAT_RANGE /
STRING_RANGE / DATE_RANGE / BINARY_RANGE
SIZE = "size" S ":" S SIZE_LIST S ";"
SIZE_LIST = UINT_RANGE / ( UINT_RANGE S "," S SIZE_LIST )
; Actual values, but INT_VALUE is too long.
INT_V = *1"-" 1*DIGIT
FLOAT_V = INT "." 1*DIGIT *1( "e" *1( "+"/"-" ) 1*DIGIT )
; DATE uses ISO short format, yyyymmddThh:mm:ss.f
DATE_V = *1DIGIT 2DIGIT 2DIGIT
*1(%x54 2DIGIT ":" 2DIGIT ":" 2DIGIT *1( "." *1DIGIT ))
INT_DEF = INT_V
UINT_DEF = 1*DIGIT
FLOAT_DEF = FLOAT_V
DATE_DEF = INT_DEF / DATE_V
STRING_DEF = ("0x" 1*( 2HEXDIG )) / ( %x22 *(%x20-7e) %x22 )
BINARY_DEF = STRING_DEF
INT_RANGE = INT_V / ( INT_V ".." ) / ( ".." INT_V ) /
( INT_V ".." INT_V )
UINT_RANGE = 1*DIGIT *1( ".." *DIGIT )
FLOAT_RANGE = ( ("<" / "<=" / ">" / ">=") FLOAT_DEF ) /
( FLOAT_DEF "<"/"<=" ".." "<"/"<=" FLOAT_DEF )
DATE_RANGE = (1*DIGIT / DATE_V) *1( ".." *(DIGIT / DATE_V) )
BINARY_RANGE = UINT_RANGE
STRING_RANGE = UINT_RANGE
STATEMENT = NAME S ":=" S DEFS S ";"
; TYPE must be defined. PROPERTIES must only use DEF and RANGE.
DTYPE = NAME S ":=" S TYPE S (PROPERTIES S *1";")/";"
Appendix C. EBML Standard definitions
define elements {
EBML := 1a45dfa3 container [ card:+; ] {
EBMLVersion := 4286 uint [ def:1; ]
EBMLReadVersion := 42f7 uint [ def:1; ]
EBMLMaxIDLength := 42f2 uint [ def:4; ]
EBMLMaxSizeLength := 42f3 uint [ def:8; ]
DocType := 4282 string [ range:32..126; ]
DocTypeVersion := 4287 uint [ def:1; ]
DocTypeReadVersion := 4285 uint [ def:1; ]
}
CRC32 := c3 container [ level:1..; card:*; ] {
%children;
CRC32Value := 42fe binary [ size:4; ]
}
Void := ec binary [ level:1..; card:*; ]
}
Appendix D. Matroska DTD
declare header {
DocType := "matroska";
EBMLVersion := 1;
}
define types {
bool := uint [ range:0..1; ]
ascii := string [ range:32..126; ]
}
define elements {
Segment := 18538067 container [ card:*; ] {
// Meta Seek Information
SeekHead := 114d9b74 container [ card:*; ] {
Seek := 4dbb container [ card:*; ] {
SeekID := 53ab binary;
SeekPosition := 53ac uint;
}
}
// Segment Information
Info := 1549a966 container [ card:*; ] {
SegmentUID := 73a4 binary;
SegmentFilename := 7384 string;
PrevUID := 3cb923 binary;
PrevFilename := 3c83ab string;
NextUID := 3eb923 binary;
NextFilename := 3e83bb string;
TimecodeScale := 2ad7b1 uint [ def:1000000; ]
Duration := 4489 float [ range:>0.0; ]
DateUTC := 4461 date;
Title := 7ba9 string;
MuxingApp := 4d80 string;
WritingApp := 5741 string;
}
// Cluster
Cluster := 1f43b675 container [ card:*; ] {
Timecode := e7 uint;
Position := a7 uint;
PrevSize := ab uint;
BlockGroup := a0 container [ card:*; ] {
Block := a1 binary;
BlockVirtual := a2 binary;
BlockAdditions := 75a1 container {
BlockMore := a6 container [ card:*; ] {
BlockAddID := ee uint [ range:1..; ]
BlockAdditional := a5 binary;
}
}
BlockDuration := 9b uint [ def:TrackDuration; ];
ReferencePriority := fa uint;
ReferenceBlock := fb int [ card:*; ]
ReferenceVirtual := fd int;
CodecState := a4 binary;
Slices := 8e container [ card:*; ] {
TimeSlice := e8 container [ card:*; ] {
LaceNumber := cc uint [ def:0; ]
FrameNumber := cd uint [ def:0; ]
BlockAdditionID := cb uint [ def:0; ]
Delay := ce uint [ def:0; ]
Duration := cf uint [ def:TrackDuration; ];
}
}
}
}
// Track
Tracks := 1654ae6b container [ card:*; ] {
TrackEntry := ae container [ card:*; ] {
TrackNumber := d7 uint [ range:1..; ]
TrackUID := 73c5 uint [ range:1..; ]
TrackType := 83 uint [ range:1..254; ]
FlagEnabled := b9 uint [ range:0..1; def:1; ]
FlagDefault := 88 uint [ range:0..1; def:1; ]
FlagLacing := 9c uint [ range:0..1; def:1; ]
MinCache := 6de7 uint [ def:0; ]
MaxCache := 6df8 uint;
DefaultDuration := 23e383 uint [ range:1..; ]
TrackTimecodeScale := 23314f float [ range:>0.0; def:1.0; ]
Name := 536e string;
Language := 22b59c string [ def:"eng"; range:32..126; ]
CodecID := 86 string [ range:32..126; ];
CodecPrivate := 63a2 binary;
CodecName := 258688 string;
CodecSettings := 3a9697 string;
CodecInfoURL := 3b4040 string [ card:*; range:32..126; ]
CodecDownloadURL := 26b240 string [ card:*; range:32..126; ]
CodecDecodeAll := aa uint [ range:0..1; def:1; ]
TrackOverlay := 6fab uint;
// Video
Video := e0 container {
FlagInterlaced := 9a uint [ range:0..1; def:0; ]
StereoMode := 53b8 uint [ range:0..3; def:0; ]
PixelWidth := b0 uint [ range:1..; ]
PixelHeight := ba uint [ range:1..; ]
DisplayWidth := 54b0 uint [ def:PixelWidth; ]
DisplayHeight := 54ba uint [ def:PixelHeight; ]
DisplayUnit := 54b2 uint [ def:0; ]
AspectRatioType := 54b3 uint [ def:0; ]
ColourSpace := 2eb524 binary;
GammaValue := 2fb523 float [ range:>0.0; ]
}
// Audio
Audio := e1 container {
SamplingFrequency := b5 float [ range:>0.0; def:8000.0; ]
OutputSamplingFrequency := 78b5 float [ range:>0.0;
def:8000.0; ]
Channels := 94 uint [ range:1..; def:1; ]
ChannelPositions := 7d7b binary;
BitDepth := 6264 uint [ range:1..; ]
}
// Content Encoding
ContentEncodings := 6d80 container {
ContentEncoding := 6240 container [ card:*; ] {
ContentEncodingOrder := 5031 uint [ def:0; ]
ContentEncodingScope := 5032 uint [ range:1..; def:1; ]
ContentEncodingType := 5033 uint;
ContentCompression := 5034 container {
ContentCompAlgo := 4254 uint [ def:0; ]
ContentCompSettings := 4255 binary;
}
ContentEncryption := 5035 container {
ContentEncAlgo := 47e1 uint [ def:0; ]
ContentEncKeyID := 47e2 binary;
ContentSignature := 47e3 binary;
ContentSigKeyID := 47e4 binary;
ContentSigAlgo := 47e5 uint;
ContentSigHashAlgo := 47e6 uint;
}
}
}
}
}
// Cueing Data
Cues := 1c53bb6b container {
CuePoint := bb container [ card:*; ] {
CueTime := b3 uint;
CueTrackPositions := b7 container [ card:*; ] {
CueTrack := f7 uint [ range:1..; ]
CueClusterPosition := f1 uint;
CueBlockNumber := 5378 uint [ range:1..; def:1; ]
CueCodecState := ea uint [ def:0; ]
CueReference := db container [ card:*; ] {
CueRefTime := 96 uint;
CueRefCluster := 97 uint;
CueRefNumber := 535f uint [ range:1..; def:1; ]
CueRefCodecState := eb uint [ def:0; ]
}
}
}
}
// Attachment
Attachments := 1941a469 container {
AttachedFile := 61a7 container [ card:*; ] {
FileDescription := 467e string;
FileName := 466e string;
FileMimeType := 4660 string [ range:32..126; ]
FileData := 465c binary;
FileUID := 46ae uint;
}
}
// Chapters
Chapters := 1043a770 container {
EditionEntry := 45b9 container [ card:*; ] {
ChapterAtom := b6 container [ card:*; ] {
ChapterUID := 73c4 uint [ range:1..; ]
ChapterTimeStart := 91 uint;
ChapterTimeEnd := 92 uint;
ChapterFlagHidden := 98 uint [ range:0..1; def:0; ]
ChapterFlagEnabled := 4598 uint [ range:0..1; def:0; ]
ChapterTrack := 8f container {
ChapterTrackNumber := 89 uint [ card:*; range:0..1; ]
ChapterDisplay := 80 container [ card:*; ] {
ChapString := 85 string;
ChapLanguage := 437c string [ card:*; def:"eng";
range:32..126; ]
ChapCountry := 437e string [ card:*; range:32..126; ]
}
}
}
}
}
// Tagging
Tags := 1254c367 container [ card:*; ] {
Tag := 7373 container [ card:*; ] {
Targets := 63c0 container {
TrackUID := 63c5 uint [ card:*; def:0; ]
ChapterUID := 63c4 uint [ card:*; def:0; ]
AttachmentUID := 63c6 uint [ card:*; def:0; ]
}
SimpleTag := 67c8 container [ card:*; ] {
TagName := 45a3 string;
TagString := 4487 string;
TagBinary := 4485 binary;
}
}
}
}
}
Ya está disponible en las tiendas on-line de estándares el borrador de la norma FprEN 16931-1 Electronic invoicing – Part 1: Semantic data model of the core elements of an electronic invoice
Todo es electrónico 