EBML Schema

Dave Rice <[email protected]> Thu, 27 Aug 2015 22:45:08 -0400
Newsgroups	gmane.comp.multimedia.matroska.devel
Message-ID	<[email protected]>
Hi all,

Next in the ebml specification work, I'd like to try and expand the section on EBML semantics in this section: https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#element-template <https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#element-template>, so that we can have more precise language on how to define EBML Elements and handle aspects of their definition such as defaults, ranges, types, descriptions, ids, and mandates. The older RFC Draft by Martin Nilsson used an analogy comparing EBML Semantics to XML Document Type Definitions (DTD), but I think it may be more modern to use an analogy between EBML Semantics and XML Schemas (XSD) and thus define how to make an EBML Schema. I think having this concept be clearly expressed will make the development of the Matroska specification (as an EBML Schema itself) a lot more clear.

I propose the specdata.xml file here https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml <https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml> is a good basis for the consideration of an EBML Schema. From what I can see, specdata.xml is an expression of the EBML + Matroska specifications to support automated creation of documentation, but the structure of this already shares a lot of similarity to XML Schemas.

But there are some differences between the ebml element attributes listed in the current EBML spec and the specdata.xml file.

The EBML spec lists these attributes for defining EBML Elements:
element name
level
id
mandatory
multiple
range
default
element type
description

to these specdata.xml adds:
bytesize
cppname
divx
maxver
minver
recursive
webm

I think it may be worthwhile to define bytesize, maxver, minver, and recursive in the EBML Schema itself. The attributes for cppname, divx, and webm seem locally specifically to matroska documents. Also potentially webm could be with a separate EBML Schema or an EBML Schema Extension based on the matroska EBML Schema.

So I have some questions:

Is there a preference in handling the standardization of Matroska: documenting it in a similar fashion to our work in the EBML spec or to define what an EBML Schema is and consider matroska an expression of it?

Are some changes to specdata.xml acceptable? Such as a filename change or changing the name of the <table> element of some attributes?

Neither the current EBML specs nor the specdata.xml specifically refer to the hierarchical arrangement of the elements, but this could be presumed by their ordering. For instance, could any level 3 element be a child of any level 2 Master-element? I presume not, but I don't think it's clear anywhere what parent-child relationships are feasible. Possibly specdata.xml and/or the EBML Schema Definition could define the relationship between levels of related elements similar to how an XML Schema (XSD) does.

Best Regards,
Dave Rice

_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
signature.asc (application/pgp-signature, 801 B)