DTD for Kdenlive

[Narcis Garcia]

I think it's a good initiative.


El 24/05/18 a les 13:14, Camille ha escrit:
> Hi all,
> 
> Still on the topic of file format. I think it could be a good idea to
> have a validating dtd for kdenlive: that could help diagnosing
> wrongly-formed files and would also be a kind-of-human-readable
> documentation for the format: as I couldn't find any in the source tree,
> I started making one from mlt-xml.dtd. Do you think it would actually be
> useful ?
> 
> It seems it shouldn't be too much work. I tried to validate a simple
> Kdenlive file against the mlt-xml.dtd and "fixed" the errors of the fly
> ; I found two categories of issues:
> 
> - Adding attributes and children elements, which is straightforward.  I
> always assumed CDATA for the type (so there is room for optimisation if
> we want stricter control: e.g the hide element could have a more
> constrained type, I guess). Just a few points that should be addressed :
>     -  In the DTD, Playlist can't be empty, as they must have a least 
> one of the following elements : (entry | blank | producer | playlist |
> property | tractor | multitrack)+. But I get an empty one in my simple
> example : which is correct ?
>     - In the DTD, tractor has a mandatory multitrack child element : 
> tractor (multitrack, (filter | property | track| transition)*) , but
> such child element never appears in my example. Should it be tractor
> (multitrack | filter | property | track| transition)+ ?
> 
> - ID /IDREF types issues. It seems that most issues related IDs has been
> fixed between "Generation 2" and "Generation 3" formats. There is one
> remaining, "main bin" as you can't have spaces in IDs
> (https://www.w3.org/TR/REC-xml/#NT-Name ). could that be fixed in the
> code, or should  we give  up on the ID/IDREFS types  and just use  CDATA ?
> 
> Cheers,
> Camille
> 
>