Re: [Cellar] EBML Schema

2015-12-04 0:50 GMT+01:00 Dave Rice <[email protected]>:
> Thanks Moritz,
>> On Dec 1, 2015, at 11:01 AM, Moritz Bunkus <[email protected]> wrote:
>>
>> Hey,
>>
>>> I’m preparing a pull request on specdata.xml but want to update the
>>> utilities in spectool at the same time so that spec2data, data2lib,
>>> and data2spec still function properly. I’m having trouble getting the
>>> spectool utilities to build properly so that I can test them.
>>
>> All of that is Steve's code and I don't know a lot about coremake and
>> the assorted build process (and there's zero documentation), but I do
>> manage to get it to compile most of the time ;)
>>
>> From a fresh checkout of the foundation repository[1] in ~/foundation:
>>
>> --------------------
>>
>> 1. Build and install coremake:
>>
>> cd ~/foundationcorec/tools/coremake
>> make
>> make install
>>
>> Unfortunately coremake has /usr/local/share/coremake hardcoded on Linux
>> for looking up its include files; therefore the "make install" is
>> actually really necessary.
>>
>> 2. Configure the rest of the project with coremake:
>>
>> cd ~/foundation
>> coremake gcc_linux_x64
>>
>> 3. Compile the tools (mkvtree, mkvalidator, mkclean; optional):
>>
>> cd ~/foundation
>> make
>>
>> 4. Compile the programs in spectool:
>>
>> cd ~/foundation
>> make -C spectool
>>
>> 5. Use the programs:
>>
>> # This creates spec.xml from specdata.xml. spec.xml is basically the
>> # HTML table you see on www.matroska.org/technical/specs/:
>>
>> cd ~/foundation/spectools
>> ../release/gcc_linux_x64/data2spec
>>
>> ——————————
>
> These instructions worked well. To help the next person who happens along, I converted your notes into a basic README which I sent as a pull request here: https://github.com/Matroska-Org/foundation-source/pull/6.
>
>>> I was able to build coremake but not sure where to go from here.
>>
>> The whole foundation repo could use a serious rewrite of its build
>> system. Steve had reasons why he created coremake, but the result is
>> very, very complicated to use. If you (or anyone else) want to give such
>> a rewrite a try I'd highly welcome it.
>
> I am interested in the foundation repo since it is the home of the Matroska instance of the basis of the conceptual EBML Schema (specdata.xml). To work on moving the current state of specdata.xml towards a more standardized EBML Schema expression I should synchronize the work on specdata.xml to the spectools so that the foundation repo doesn’t break because of IETF work.
>
> The rest of the foundation repo may be out of scope to the charter. There is obviously a lot of documentation on Matroska use on matroska.org but that appears to be based in your Drupal site rather than this repo.

If you're referring to the documentation in the HTML tables on
matroska.org, they are taken from the specdata.xml after the HTML is
generated, not the other way around.

> I think we still need a good method to handle linking pull requests, comments, and discussion upon the Matroska documentation. Drupal makes this a bit difficult. Should we move some of this documentation to GitHub as well and have a similar process as spec.xml with the other documentation (i.e. build it from a repo and copy/paste it to Drupal). Or potentially we could move some Matroska documentation from Drupal to GitHub gh-pages as done with the EBML Specification website (formerly on sourceforge).

I agree, it will be much easier to do things on Github.

>>> Any advice on which route to take: continue trying with getting
>>> spectool utilities to build or redo the utilities in xsl?
>>
>> I'd prefer established technologies like XSLT in this case as it allows
>> you to use a plethora of proven tools like xsltproc or any other XSLT
>> processor (Saxon?). You can (and should) still build the tools with the
>> instructions above so that you verify stuff works :)
>
> This is verified. If XSLT is welcome I certainly think it’s much more familiar.

Not to me, but it shouldn't too hard to adapt the spec tools to match
field name changes at the same time. If XSLT can also generate the
C/C++ code matching the semantics, then it's great. That should make
it easier for people to create their own EBML format and play with the
code while defining it.

> Thanks,
> Dave Rice
>
>> Kind regards,
>> mosu
>>
>> [1] https://github.com/Matroska-Org/foundation-source/
>> _______________________________________________
>> Cellar mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/cellar
>
> _______________________________________________
> Cellar mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cellar



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