Could you point me to your slides from the last OGF? I'd like to be able to have multiple entities in each JSON document for easier publishing. I may require it depending on how we represent associations - there are a couple places where XSEDE wants ComputingActivities in queue order. I think a good goal would be to allow JSON documents to have many GLUE2 entities in them, or just one entity. I'm using 3 documents right now (single computing activity, multiple computing activities, and everything else), but I may split the larger documents up when storing them in a document-oriented database. I *think* the example documents I sent could be split this way without a problem. One issue I had was how to identify a particular JSON object as a specific GLUE2 entity. To do this I did: "GLUE2 Entity Name": { attributes } If there can be at most 1 entity of that type (e.g. ComputingService). If there can be multiple entities (e.g. ComputingShare) I did: "GLUE2 Entity Name": [ { attributes }, { attributes }, ] even if a particular document only had 1 of these entities. I did this so that it was a bit easier to process the document. Oh, I just noticed that the ResourceID and SiteID members shouldn't really be in the documents I sent. They are some legacy metadata and aren't glue2 and I probably don't need them, anyway. Warren From: Shiraz Memon [mailto:a.memon@fz-juelich.de] Sent: Thursday, October 04, 2012 4:25 AM To: Warren Smith; OGF GLUE WG Subject: Re: [glue-wg] JSON rendering Hi Warren, I think there was at least one other project that created their own JSON rendering. Is mine in the same ballpark as yours? Not exactly, the way we use is bit more "flattened" where each attribute is prepended with the owning entity/class name and an underscore; e.g. Endpoint_ID. Since the scope within EMIR is limited to address the endpoints only, therefore we didn't care about other glue 2 entities. To get more insight, have a look into my slides from last OGF[1]. Are there folks interested in defining an official JSON rendering? Yes, having JSON rendering for glue 2 would be more than nice to have for non-XML based services. If possible, I would recommend to have a slot in GLUE session at ogf 36 to kick-start this activity. I had a short glimpse over your documents, and got slightly concerned about representing all the entities (while considering the glue 2 spec.) in a single json document for the future standard rendering, thus going to make it very complex and prone to validation errors. Wouldn't that be simplified if for every (or at least major) glue entity/class to be defined in a separate JSON document. This surely won't hamper the developers from using the merged documents. [1] http://redmine.ogf.org/dmsf_files/145?download= Cheers, Shiraz Warren _______________________________________________ glue-wg mailing list glue-wg@ogf.org<mailto:glue-wg@ogf.org> https://www.ogf.org/mailman/listinfo/glue-wg -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app

I don't have a need for any Service or Endpoint objects right this minute, so I don't have examples. I've got ComputingService and ComputingEndpoint in the glue2_pbs_public.json file that I sent earlier, though. I'd expect to do Service and Endpoint the same way, but with a subset of the attributes. Warren From: Shiraz Memon [mailto:a.memon@fz-juelich.de] Sent: Friday, October 05, 2012 4:58 AM To: Warren Smith Cc: OGF GLUE WG Subject: Re: [glue-wg] JSON rendering On Thu, Oct 4, 2012 at 7:35 PM, Warren Smith <wsmith@tacc.utexas.edu<mailto:wsmith@tacc.utexas.edu>> wrote: Could you point me to your slides from the last OGF? here is a link to the slides: http://redmine.ogf.org/dmsf_files/145?download= and an example JSON document: http://eu-emi.github.com/emiregistry/documentation/registry-1.2.0/emir-manua... It is obvious that the JSON documents therein does not reflect glue structure at all, however the entity names and attributes. We have also introduced a couple of extra attributes, such as, "expire_on" - where publisher can specify TTL value of that particular document - or _id though uninteresting for the user, assigned by the document database. I'd like to be able to have multiple entities in each JSON document for easier publishing. I may require it depending on how we represent associations - there are a couple places where XSEDE wants ComputingActivities in queue order. I think a good goal would be to allow JSON documents to have many GLUE2 entities in them, or just one entity. I'm using 3 documents right now (single computing activity, multiple computing activities, and everything else), but I may split the larger documents up when storing them in a document-oriented database. I *think* the example documents I sent could be split this way without a problem. One issue I had was how to identify a particular JSON object as a specific GLUE2 entity. To do this I did: "GLUE2 Entity Name": { attributes } If there can be at most 1 entity of that type (e.g. ComputingService). If there can be multiple entities (e.g. ComputingShare) I did: "GLUE2 Entity Name": [ { attributes }, { attributes }, ] even if a particular document only had 1 of these entities. I did this so that it was a bit easier to process the document. mapping the entities as you've mentioned above was my first thought while designing the json template, however due to the requirements we shrank and packed the entities into a single level objects (i.e. service and endpoint at the same level). We have to see whether the aforesaid approach - which seems to be quite natural - is feasible for us. It would be very helpful if you have any example showing "Service" and "Endpoint" entities. Thanks, Shiraz Oh, I just noticed that the ResourceID and SiteID members shouldn't really be in the documents I sent. They are some legacy metadata and aren't glue2 and I probably don't need them, anyway. Warren From: Shiraz Memon [mailto:a.memon@fz-juelich.de<mailto:a.memon@fz-juelich.de>] Sent: Thursday, October 04, 2012 4:25 AM To: Warren Smith; OGF GLUE WG Subject: Re: [glue-wg] JSON rendering Hi Warren, I think there was at least one other project that created their own JSON rendering. Is mine in the same ballpark as yours? Not exactly, the way we use is bit more "flattened" where each attribute is prepended with the owning entity/class name and an underscore; e.g. Endpoint_ID. Since the scope within EMIR is limited to address the endpoints only, therefore we didn't care about other glue 2 entities. To get more insight, have a look into my slides from last OGF[1]. Are there folks interested in defining an official JSON rendering? Yes, having JSON rendering for glue 2 would be more than nice to have for non-XML based services. If possible, I would recommend to have a slot in GLUE session at ogf 36 to kick-start this activity. I had a short glimpse over your documents, and got slightly concerned about representing all the entities (while considering the glue 2 spec.) in a single json document for the future standard rendering, thus going to make it very complex and prone to validation errors. Wouldn't that be simplified if for every (or at least major) glue entity/class to be defined in a separate JSON document. This surely won't hamper the developers from using the merged documents. [1] http://redmine.ogf.org/dmsf_files/145?download= Cheers, Shiraz Warren _______________________________________________ glue-wg mailing list glue-wg@ogf.org<mailto:glue-wg@ogf.org> https://www.ogf.org/mailman/listinfo/glue-wg -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899<tel:%2B49%202461%2061%206899> Fax: +49 2461 61 6656<tel:%2B49%202461%2061%206656> ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unsere app? http://www.fz-juelich.de/app -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656

Understood. I'll have problems if I'm unable to express an ordering in a rendering, though. Thinking about our discussion yesterday, maybe this is part of our XSEDE profile... Warren

-----Original Message----- From: stephen.burke@stfc.ac.uk [mailto:stephen.burke@stfc.ac.uk] Sent: Friday, October 05, 2012 9:33 AM To: Warren Smith; a.memon@fz-juelich.de; glue-wg@ogf.org Subject: RE: [glue-wg] JSON rendering

glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith said:

...

there are a couple places where XSEDE wants ComputingActivities in queue order.

As an observation, the schema doesn't have a general concept of ordering - you can potentially define it for a specific implementation but it probably wouldn't survive translation to another format.

Stephen

-- Scanned by iCritical.