[Matroska-devel] EBML Schema
moritz at bunkus.org
Fri Aug 28 08:50:03 CEST 2015
I have no objections, however I don't know a lot about XML schemas in
the first place (neither about DTDs, to be honest).
> I propose the specdata.xml file here
> 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.
For both documentation (e.g. the table on the matroska.org specs page is
generated from this file) and code (libMatroska's class hierarchy is
generated automatically from this file) actually.
> 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
I'm not sure whether or not I understand the implications. But my gut
feeling is that having a definition for an EBML Schema would benefit
other formats than Matroska, too, therefore the latter seems the way to
> Are some changes to specdata.xml acceptable? Such as a filename change
> or changing the name of the <table> element of some attributes?
Well, like I said above the specdata.xml is used for generating both
documentation and code. Both should stay viable. If changes to it are
made then the accompanying tools must be updated as well.
> 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.
So far it is understood that an element not marked as a global element
must only occur as a child of its parent. Its parent is the last element
located before the child element in the specdata file with a lower level
than the child element. Or something like that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Matroska-devel