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

2015-12-08 14:17 GMT+01:00 Dave Rice <[email protected]>:
>
>> 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.

I think there can be more than one validator. One using XML is
certainly useful. On the other hand, given the tight binary nature of
EBML, it may produce very large files. But it will probably be limited
to basic EBML. For example for Matroska it would be tricky to verify
Cues refer to proper Clusters/frames without being able to seek in the
XML file or keep everything in memory. The C based validator is being
"smart" about this and keeps things in memory depending on the mode
it's being used. It also uses the tight in-memory representation of an
EBML element. Whereas an XML parser will likely use a lot more memory
for each possible named element.

> 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?

That would be a nice goal. But as described above, some further checks
may not be possible with such an approach.

-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
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