Re: [Cellar] Defining EBML Schema in the EBML spec & mandatory/default

Hi Michael,

> On Dec 7, 2015, at 12:37 PM, Michael Bradshaw <[email protected]> wrote:
> 
> On Sat, Dec 5, 2015 at 10:58 AM, Dave Rice <[email protected] <mailto:[email protected]>> wrote:
> The specdata.xml <https://github.com/Matroska-Org/foundation-source/blob/3414f292bb5b1ac5ee2fd99976b7274fd81e48ee/spectool/specdata.xml> file is the only precedent expression of an EBML Schema that I know of. Is there a machine readable expression of webm anywhere? Or any other EBML Document Type?
> 
> Not that I know of (there certainly isn't anything normative like that for WebM). I'm really looking forward to a standardized machine readable form, because it'll help keep the WebM and MKV specs consistent. Right now they've fallen out of sync (i.e. WebM marks several elements as supported, like BlockVirtual, BlockAdditions, MaxBlockAdditionID, etc that aren't marked as supported in WebM within the MKV spec).
> 
> Considering your points about nailing down the definition of range, there are only a few range values in use in specdata.xml, “> 0”, “>0”, “0-1”, “1-254”, and “not 0”, I made some notes of a definition of these in a pull request comment <https://github.com/Matroska-Org/ebml-specification/pull/40#discussion_r46761573>, but propose that ultimately we move the definition of `range` towards the XML Schema equivalent of `restriction` <http://www.w3schools.com/Xml/schema_facets.asp>.
> 
> Something along the lines of XML Schema restriction would probably be nice, because then you could use it for strings and the like.

One caution I have here is that the current specdata.xml file is used to create libraries that are used to build mkvalidator. I think possibly a different specdata.xml could be used to create a validator from mkvalidator code for another EBML format. However, mkvalidator likely does not support much outside of the current `range` values. If we use something broader like XML Schema's restriction we could end up making EBML Schemas that can not be used within mkvalidator. On the other hand, support for string restrictions would allow us to have a machine-readable test on Matroska tags, whereas we 

If we standardize EBML Schema, I think it's practically essential to have a utility that can use the EBML Schema to validate an EBML Document. To do that there is mkvalidator and inside the PreForma project there is work underway to build an EBML validator using a combination of MediaTrace and XSL.

Cc'ing matroska-devel on this, but I like to ask:
If EBML Schema is extended to support more comprehensive expressions that specdata.xml currently supports, are there volunteers to update mkvalidator to support the new EBML Schema? I can volunteer to update data2spec to produce a similar output but feasibly our work on EBML Schema may mean that it then continues unpredicted expressions.

An alternate could be to say that EBML Schema has X features but that the Matroska specification adds T constraints onto the implementation of the schema, so that the only Matroska EBML Schema is semantically equivalent to specdata.xml

> Regarding the conflicts of the spec regarding the meaning of Empty Elements versus how the default value applies to an Empty Element, I remember this discussion but forgot about it while drafting. I’ll add this in shortly, it will be nice to finally have rules about default/mandatory/empty all centralized as the discussions and clues have been widespread.
> 
> Great, looking forward to that. I'll review that when it's up.

I'll probably do this by adding another paragraph and then another column that that lookup table that I started.
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