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

2015-12-07 19:04 GMT+01:00 Dave Rice <[email protected]>:
> 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]> wrote:
>>
>> The 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, but propose that ultimately we move the definition of
>> `range` towards the XML Schema equivalent of `restriction`.
>
>
> 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.

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).

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



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