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

Hi all,

> On Dec 8, 2015, at 8:17 AM, Dave Rice <[email protected]> wrote:
> 
> 
>> On Dec 8, 2015, at 4:20 AM, Steve Lhomme <[email protected]> wrote:
>> 
>> 2015-12-07 19:04 GMT+01:00 Dave Rice <[email protected]>:
>>> 
>>> On Dec 7, 2015, at 12:37 PM, Michael Bradshaw <[email protected]> wrote:
> 
> […]
> 
>>> 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.
>> 
>> If we go the XSLT way, I suppose a more flexible validator could be
>> written using that and be easily updated on the fly, compared to a
>> compile program like mkvalidator.
>> 
>>> 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.
>> 
>> I will continue maintaining mkvalidator, until another validator
>> supports all the same error/warning detections and profiles (live,
>> webm, divx).
> 
> Thanks Steve.
> 
> I realize that another approach we could use is to convert EBML to XML and then validate the resulting XML with an XML Schema that defines an EBML format. This would means that we could use any XML validator instead of necessarily needing a custom EBML validator. There is already an EBML<->XML converter here https://github.com/vi/mkvparse/. An EBML validator could work like this:
> 
> mkv2xml < test.mkv > output.xml
> xmllint --noout --schema output.xml
> 
> I note that mkvalidator has some tests that are analogous to XML validation against an XML Schema, but some are rules more similar to Schematron. I’ll have to see if these rules could possibly to stored properly in an XML Schema to verify if we’d need a second schematron-like test.
> 
> Ideas? re: Updating mkvalidator to validate an EBML Dcoument validator against an EBML Schema. Or. Using existing XML validation tools with an EBML->XML conversion?

This conversation continued in GitHub on the pull request here https://github.com/Matroska-Org/ebml-specification/pull/40. Moritz merged the PR though some issues remain for another one, such as defining how to express EBML Element defaults when the default value may be a string, integer, or reference to another Element’s value.

The new merge adds a section on defining an EBML Schema, https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema. The current in-use EBML Schema is specdata.xml which is here https://github.com/Matroska-Org/foundation-source/blob/master/spectool/specdata.xml. Now that we have a definition for specdata.xml, I suggest we draft a new PR that updates the EBML Schema definition to bring it into as much alignment with XML Schema’s specification as we can. Alongside this i can update the XSL that converts the EBML Schema into spec.xml which is used for documentation in the matroska.org website and as a definition for use in mkvalidator.

I think the EBML Specification is getting close to complete. There are some open issues here, https://github.com/Matroska-Org/ebml-specification/issues, some of which relate to missing pieces of the spec and sections needed to bring the spec moreso towards RFC style (adding a Security Consideration section). Volunteers?

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