On Thu, Jun 14, 2012 at 8:13 AM, Paul Millar
<paul.millar@desy.de> wrote:
Hi JP,
On Wednesday 13 June 2012 12:02:05 JP Navarro wrote:
> iv) Future directions discussion: JSON rendering, etc.
How serious are we with the idea of another rendering? I'm thinking of JSON
in particular, which seems to pop up as a "nice to have", which I'm not sure
if anyone's actively working on.
The reason for asking is that within EMI there was a group (EMIR) that are
working with GLUE 2.0 and, in effect, created their own JSON rendering of GLUE
2.0, although they didn't seem to realise that's what they did -- or, at
least, haven't contributed it back to the GLUE WG.
I think what they have developed will work for their particular use-case, but
their rendering isn't well documented and (reverse engineering the format it
in my head) I suspect isn't generally applicable for all the expressive power
of GLUE 2.0.
True, the rendering has been developed for the specific use case.
The reason behind having this topic on the ogf session agenda is to introduce the EMIR(1) way of json rendering, along with discussion regarding its improviements, alternative styles (nested vs. flat), etc...
(1) a service endpoint registry developed within the EMI project.
I am also summarising EMIR json rendering below for better understanding.
In EMIR, the json rendering doesn't cover all the entities of the specification, but a smaller subset covering the Service and Endpoint classes. The attributes therein are flattened and separated by underscores ("_"), for example the Service ID is expressed
as Service_ID and Service Endpoint ID as Service_Endpoint_ID. There are also additional attributes containing the metadata, such as lifetime, owner to control the registrations. For the successful registration, every document must define Service_Endpoint_URL
(instead of the Service_Endpoint_ID), thus URL uniquely identifies documents in the collection. Off course this is not according to the GLUE 2 specification where the IDs are unique, but due to easier tracking of records (while being stored in multiple EMIR
servers) we thought of URL as the meaningful handles. Again, using unique IDs is technically possible too, however the publisher has to keep track of their registrations (json documents) with the IDs instead of URLs.
The link to the example json document
Since we do not have any official GLUE2 json rendering yet, having EMIR's json might be the starting point.
I've tried to encourage them to take part in a standardisation effort, but not
had too much success so far. I'll keep trying.
I disagree, you aren't unsuccessful so far :)
Best regards,
Shiraz
Cheers,
Paul.