Subject: [Lager] Next Steps for LAGER

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Feb 2016 12:52:49 +0000

Thinking ahead a bit...

First, we won't be meeting at IETF-95. We don't have anything to do that compels us to meet in person. That's a good thing!

Our charter currently has only one milestone: complete draft-ietf-lager-specification by December 2015. We missed the date, but that document is almost ready for submission to the IESG. Once it's finished we can declare victory and close this WG, but first we should ask ourselves if there's more work to do.

One thought is that we could consider adding a new milestone to our charter if we have an identified work item and WG consensus to do more work. I'm aware of another Internet-Draft that might be appropriate for us to work on:

https://datatracker.ietf.org/doc/draft-schiltknecht-lgr-json/

This document is currently expired. Once the XML-based LAGER specification has been completed it should be relatively easy to document a complementary JSON specification that is derived from, and consistent with, the XML specification.

Does this (or anything else) sound interesting to anyone? If not, should we conclude our work when draft-ietf-lager-specification is finished?

Scott

---

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 22 Feb 2016 08:04:25 -0500

On 22 Feb 2016, at 7:52, Hollenbeck, Scott wrote:

> Thinking ahead a bit...
>
> First, we won't be meeting at IETF-95. We don't have anything to do 
> that compels us to meet in person. That's a good thing!
>
> Our charter currently has only one milestone: complete 
> draft-ietf-lager-specification by December 2015. We missed the date, 
> but that document is almost ready for submission to the IESG. Once 
> it's finished we can declare victory and close this WG, but first we 
> should ask ourselves if there's more work to do.
>
> One thought is that we could consider adding a new milestone to our 
> charter if we have an identified work item and WG consensus to do more 
> work. I'm aware of another Internet-Draft that might be appropriate 
> for us to work on:
>
> This document is currently expired. Once the XML-based LAGER 
> specification has been completed it should be relatively easy to 
> document a complementary JSON specification that is derived from, and 
> consistent with, the XML specification.
>
> Does this (or anything else) sound interesting to anyone?

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

Marc.

> If not, should we conclude our work when 
> draft-ietf-lager-specification is finished?
>
> Scott
>
> _______________________________________________
> Lager mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lager

---

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 26 Feb 2016 14:35:17 +0900

> interpretation of the mapping. Vcard-xcard-jcard was done similarly.

+1

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 26 Feb 2016 18:26:58 +0900

>> interpretation of the mapping. Vcard-xcard-jcard was done similarly.

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.

Regards,   Martin.

---

From: Asmus Freytag <[email-masked]>
Date: Fri, 26 Feb 2016 02:23:58 -0800

On 2/26/2016 1:26 AM, Martin J. Dürst wrote:
> 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).
>

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

---

From: "Marc Blanchet" <[email-masked]>
Date: Fri, 26 Feb 2016 07:11:49 -0500

On 26 Feb 2016, at 4:26, Martin J. Dürst wrote:

> that LAGER data won't be as widely used as Vcard-xcard-jcard.

of course.

> And there must have been some reason for why it was started with XML 

yes. already.

Marc.

---

From: Wil Tan <[email-masked]>
Date: Sat, 27 Feb 2016 18:39:23 +1100

On Fri, Feb 26, 2016 at 11:11 PM, Marc Blanchet <[email-masked]>
wrote:

> 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.
>
> of course.
>

It is a fairly lightweight and simple transformation specification, so if
there's a use case for it I would vote for the draft to be taken on.

.wil

Marc.
>
> 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.
>
> Regards, Martin.
> ------------------------------
>
> Lager mailing list
> [email-masked]