June 2012 - glue-wg - lists.ogf.org

flat xml rendering
by david.meredith＠stfc.ac.uk 04 Oct '12

04 Oct '12

Hi all, Following OGF 35 I have produced an updated draft of the XSD: http://tools.ngs.ac.uk/ngstools/glue2proposal/flat.zip This rendering has a 'flat' style and includes the global <Entities> element bag with abstract elements/substitution groups. There are a few choices that still need to be addressed which are highlighted with TODO annotations (please do a search on 'TODO' in glue2_2.xsd). A sample instance document is also provided (glue2_2SampleDoc1.xml). For the purposes of demonstration, there is also a sample XSD (sampleGlue2_2Extension.xsd) that imports the glue2_2.xsd to define new service and endpoint element types. This shows how future profiles could extend the glue XSD in order to define new sub-type specialisations (also see the sample instance doc, sampleGlue2_2ExtensionDoc.xml). I guess the next step is to do another telephone conf to agree/disagree. If possible, i would prefer to do this before spending too much effort on updating the Word doc. Cheers, David ========================== David Meredith Scientific Computing Technology eScience Daresbury Laboratory Tel: +44 (0) 1925 603762 Fax: +44 (0) 1925 603100 (Site) Email: david.meredith(a)stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.

4 14

OGF35 GLUE WG summary
by JP Navarro 19 Jun '12

19 Jun '12

Greetings GLUE WG, Summary of the discussions held in the GLUE WG session at OGF35 on Sunday, June 17, 2012. Many thanks for the strong participation with close to 20 present in person and 2 joining over Skype. Regards, JP and Shiraz Discussion Summary 1. XML Rendering ================ We discussed the pros and cons of hierarchical, hybrid, and flat. Flat rendering Pros ------------------- * We propose that elements can only appear in one place in a valid GLUE2 document ** Ensuring that elements can't be duplicated * Makes it easier to publish subsets of information * Element can be cross-referenced * Easier to generate and publish * Easier to cherry pick desired elements to import into external schemas Flat rendering Cons ------------------- * Harder to construct complex queries ** Parent/child relationships followed using nested queries Hierarchical Pros * Easier to construct complex queries * Naturally preserves parent/child relationships Hierarchical Cons ----------------- * Very hard to "slice" big document into pieces * Duplication of information may happen under different parents * Publishing subsets and merging is hard to implement * Must still use cross-references to content published in separate documents * The parent-child relationship mandated is sometimes too strict Hybrid Pros and Cons -------------------- * Inherited from both Flat and Hierarchical * Has information duplication Discussed that a flat to hierarchical translator could be developed once for the entire community if we determine that some consumers require the hierarchical rendering to perform certain queries. Adopted/Approved ---------------- # Flat rendering # Root “glue:Entities” element required for GLUE2 documents # Main elements are also global (can be Root) to enable inclusion by other schemas # Substitution groups for main element classes to facilitate consistency and adoption by other schemas Action Items ------------ # New XML rendering document in 4 weeks # New XML schema in 4 weeks # Follow OGF process to approve rendering and schema documents LDAP Rendering ============== Extensively discussed whether to publish a DIT or not. Universal agreement that we should not mandate a DIT. We will discuss in a future teleconference the pros and cons and decide whether to publish. Note that if we publish the DIT could be an implementor experience document. Naming Enumerations and Types ============================= We plan to discuss and implement a team based process for reviewing proposed Enumeration and Types for adoption and for publishing in a shared public location. Perhaps this could be part of a GLUE profile that applies to all the renderings. JSON Rendering ============== Shiraz presented the EMI Services JSON rendering. We will discuss JSON renderings in future teleconferences.

2 1

LDAP rendering document: new version as an outcome of Lund review
by Balazs Konya 18 Jun '12

18 Jun '12

Dear All, I've just uploaded a new version of the "GLUE v. 2.0 – Reference Realization to LDAP Schema" ldap rendering draft to the glue2 gridforge area. The uploaded new version contains comments and tracks all the changes we made in the document. Please find the files here: - word with all the changes tracked: https://forge.ogf.org/sf/go/doc15518?nav=1 - clean pdf: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue-wg/docman… - pdf with all the changes tracked: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue-wg/docman… During the last weeks (months) the NorduGrid/ARC team in Lund carried out a thorough review and major cleanup of the ldap rendering document. Basically we took the document and checked it against our and other LDAP implementations. The ldap rendering draft was created long time ago and since 07/01/2010 it was not touched, at many places it became obsolete. Furthermore, back then when the ldap rendering discussion took place there was only one ldap implementation (the glite-bdii), unfortunately ARC was busy with the xml glue2 rendering part and had no possibility to check/follow the ldap area. Furthermore, the ldap team did not follow the xml rendering discussions although there is quite similarity in the two data models. Now that ARC implements both an LDAP and XML rendering (i think we are the only one) we thought it was time to review and update the LDAP rendering draft. Here are some of the items we modified or run into (everything is tracked in the new version!): - The old document contained a proposed DIT that was incomplete and not followed by any of the actual implementations. We almost completely rewrote the section on DIT, introduced three-level information structuring and provided three detailed pictures that correspond to actual implementation apart from minor proposed changes. - while defining the proposed DIT we tried to keep it in sync with the XML rendering, this was most visible in the selection of the grouping elements - corrected the datatypes to match the current schema used by EMI - made a comment on the usage of structural vs. auxiliary types. The current limited usage of structural types are questionable. - made a comment on the strange and unjustified (for us) choice on the LDAP attributenames selected to form DNs - made a note on the unfortunate choice of GLUE2GRoupID attribute that is not an ID - followed the RFC4512 terminology (e.g. renamed ldap objects to ldap entries) - to be consistent with the xml and sql rendering documents changed "implementation" to "realization" all over the text - made a note that the used OID allocation mechanism is not extensible when it comes to adding attributes to entry. Furthermore, the choice is strange, it is not applied consistently and its benefits are unclear. Florido will attend the OGF Glue2 session this Sunday and prepares a short presentation about our LDAP draft rendering review including open questions and proposed changes. regards, Balazs Konya and Florido Paganelli

5 11

OGF 35 meeting and preparation reminder
by JP Navarro 17 Jun '12

17 Jun '12

Dear GLUE WG, Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time. http://ogf.org/gf/event_schedule/index.php?id=2530 Our agenda: i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc. Recent action items to prepare for this meeting: Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP We will post meeting call-in information when it's available. Regards, JP

12 22

XML rendering comments
by Warren Smith 15 Jun '12

15 Jun '12

Hi all, Below are some comments about the current hybrid XML rendering (we talked about a lot of them on the last call): * Not all elements can currently be at the top level. Examples are ComputingShare, ComputingEndpoint, and several storage ones. I think major elements like these should also be allowed at the top level for consistency as well as not needing placeholder parent elements to have a valid glue2 document with this information. * I think that allowing a generic top-level element ("glue" or whatever) would be good. It would make it possible to have documents with several somewhat unrelated entities without forcing a lot of dummy hierarchical structure. For example, a document that has ComputingActivities and ExecutionEnvironments. I don't know of anyone that needs this example specifically, but I can imagine someone wanting to publish documents that contain the more dynamic information like this. * A different question is whether there should only be a generic top-level element (in contrast to the current approach that allows many of the entities to be the top-level element). I think I prefer to have a single top-level element and allow any of the entities to be under that element (with minOccurs="0"), just so that we have a little more predictable document structure. Based on the call, I don't think we'd have a consensus about this. * Something to think about is how to represent associations that aren't represented hierarchically (or aren't always represented hierarchically). An example is ComputingActivity and ComputingShare. In the current schema, ComputingShare_t has a associations to ComputingActivities using ID_t. ComputingActivity_t has a reference to a ComputingShare using a LocalID_t (I'm not sure how a LocalID differs from an ID, actually). I think that it may be better if the many refer to the one than having the one refer to the many or to refer both ways. By this I mean that ComputingActivity_t should include the LocalID_t of its ComputingShare, but ComputingShare_t should not include the ID_t of its ComputingActivities. I prefer this approach because in general I think that the "many"s may be updated more often than the "one"s (e.g. ComputingActivities may be updated more frequently than ComputingShares) and if the "one"s refer to the "many"s, they are forced to be updated. * Related to the above, I saw that ComputingActivity_t doesn't have a ComputingEndpointID element. Perhaps it should, depending on which direction we're representing associations. * A minor question is why have XXXies in the complex types? For example, ComputingActivities in ComputingEndpoint_t? An alternative is to just have ComputingActivity with maxOccurs="unbounded". Thanks and sorry for having so many points in one email, Warren

3 2

GLUE WG teleconference reminder, Thursday, May 31, 2012
by JP Navarro 01 Jun '12

01 Jun '12

Greetings Glue WG, Coordinates and agenda for tomorrow's GLUE WG teleconference follow: *NOTE* 14:00-15:00 Central Europe and 8:00-9:00 AM US Eastern (versus 9:00-10:00 AM US Eastern) Coordinates: : Thursday, May 31, 2012 : 14:00-15:00 Central Europe, 8:00-9:00 AM US Eastern Teleconference and screen sharing: : https://webconf.vc.dfn.de/ogf-glue-wg/ (Adobe Connect) : Login as Guest using your real name Agenda: 1) Proposal to introduce Service and Endpoint substitution groups by David Meredith (20 minutes) Discussion points: a) Review draft changes circulated by David, both the approach and chosen elements b) Next steps: Vote to approve at OGF35? Upload to Grid Forge? Any other next steps? Rendering document token-pen: David 2) Finalizing an XML rendering agreement (20 minutes) Discussion points: a) Can XSEDE adopt the globalized schema? b) Do we have an agreeable set of globalized elements? c) How to represent cross-references/associations for globalized elements? Background material: - Globalized schema: https://github.com/OGF-GLUE/XSD/blob/master/schema/GLUE2.xsd - TeraGrid/XSEDE schema: https://github.com/OGF-GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd 3) Other proposed/outstanding GLUE2 changes (10 minutes) a) EGI service name and type values. Put the list of service names and type enumeration values on Google doc per our last meeting? Who? b) Status of LDAP proposed changes, who has them and can circulate them? 4) Plan OGF 35 meetings (10 minutes) OGF 35 in Delft, Sunday, June 17, 13:30-15:00, room 1.180 Call-in ability arrangements (Shiraz) Possible OGF 35 agenda: i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) XSEDE and globalized schema iv) GLUE2 JSON rendering, scope, flat, etc. See you tomorrow, Shiraz Memon JP Navarro

3 2