Re: [Lager] Next Steps for LAGER

[Asmus Freytag <[e-mail]>]

On 2/26/2016 1:26 AM, Martin J. Dürst wrote:
> On 2016/02/26 14:35, Yoshiro YONEYA wrote:
>>> <no hat>Given that almost everything is now developed using JSON
>>> instead
>>> of XML, it would be much better to have a clear specification on how to
>>> implement the XML-JSON-XML mapping, instead of everyone having his own
>>> interpretation of the mapping. Vcard-xcard-jcard was done similarly.
>>
>> +1
>
> I agree that we want a single JSON mapping, not many. And I agree that
> a lot of stuff these days is done using JSON, not XML. But my guess is
> that LAGER data won't be as widely used as Vcard-xcard-jcard. And
> there must have been some reason for why it was started with XML
> (which I don't know, but would like to know).
>
> So if there are already people looking around how to do this in JSON,
> then it makes sense to nail it down. But starting this work just based
> on the hunch that somebody is eventually going to use some JSON for it
> would be the wrong thing to do in my opinion.

I tend to agree on not doing work that isn't immediately going to 
benefit critical implementations.

As for the original choice of serialization for the LGR data, I'm not 
sure that there's anything useful to be learned. The work had already 
been started based on XML. I'm not sure that working in any other 
framework would have had any concrete advantages for me.

In my implementation, the internal data structures look quite different 
from the serialized ones, because they are centered on the operations 
that need to be performed, and not primarily focused on providing a 
clear and unambiguous description of the data as such. The XML format 
and RelaxNG schema seemed well suited to providing that description, so 
no reason for me to push the project into any different direction.

In the meantime, I've developed an HTML representation of the LGR which 
by now has become my preferred format to view and review LGR data and 
rules. Again, it departs from the way the XML tables are laid out to a 
large degree, because transforming the data like that makes it easier to 
process for a human reader. (It's different yet again from the internal 
data structures, so, again, the serialization isn't simplistic).

A./