[glue-wg] GLUE 2.0 XSD Rendering - progress update

Warren Smith wsmith at tacc.utexas.edu
Mon May 2 13:59:18 CDT 2011


I've been looking at the XML schema a bit and I don't see anything in there that would mean we couldn't do what we're doing now on TeraGrid. I do see a few things that could be improved with this schema. In some places, it specifies a structure like:

<Foos>
    <Foo>
        ...
    </Foo>
    <Foo>
        ...
    </Foo>
</Foos>

I don't see any need for the Foos element to contain multiple Foo elements.

I also see that a number of the top-level elements don't have a minOccurs="0", so they are required, but probably shouldn't be. Similarly, they don't have a maxOccurs, so each one can only occur once (which doesn't make sense for some of them). I assume these are just mistakes.

One thing to think about is whether or not you want to have a top level element to contain everything. For example, an element named glue2 (for the TeraGrid GLUE 2 schema I used a top level element of Entities, which is a bit generic). The main benefits I can see to having a single top level element are that it might be easier to search for GLUE 2 documents in an XML database and it might be easier to embed a GLUE 2 document inside another XML document.



At a higher level, I'll throw out my preference again for a "flat" rendering approach (like the TeraGrid one). I see that this schema is about half way to a totally flat approach by representing the many-to-many associations with IDs. I see that a fair amount of analysis (the table and diagram in the document) had to be done to get to the point and it might be simpler all around to just go all the way and use IDs for all associations and make things consistent.

I also still do prefer the flat approach so that it is easier to construct documents with a subset of the GLUE 2 information. We wouldn't have to try to construct a hierarchy of GLUE 2 information (that we don't care about in that context) to have a valid GLUE 2 document with the information we are interested in. For example, if we just want to publish information about the ComputingEndpoints for a cluster.

There is also an implication to a flat hierarchy that I like - a single GLUE 2 document may only have partial information about a resource or grid and may need to be composed with other documents for the full picture. This makes sense to me because some parts of GLUE 2 are relatively static and probably entered manually (domains, locations, contacts), some parts are dynamic but can be discovered automatically from the right system (compute-related stuff for clusters from a login node), and others are somewhat dynamic and may be discoverable from the right system (storage-related stuff from the storage system). I think it would be nice if these documents can be constructed independently, not have extraneous information, and still be valid GLUE 2 documents before they get merged (if they do get merged).


Warren


-----Original Message-----
From: glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of Sergio Andreozzi
Sent: Monday, April 11, 2011 6:49 AM
To: OGF GLUE WG
Subject: [glue-wg] GLUE 2.0 XSD Rendering - progress update

Dear all,

I'm happy to announce that a concrete progress was made in aligning
the XSD document to GLUE 2.0 final. This is a very delicate work which
needs a focused activity and, being delayed for too long, we decided
to run a face-to-face meeting at the end of March to make progress.
Adrian Taga, Balazs Konya, Shiraz Memon and I met in Lund (Sweden) and
worked two full days with the participation of Paul Millar from
remote. Thanks to this effort, we managed to update the GLUE XSD and
the related descriptive document which now need the final make-up
before submitting them for the last call and subsequent public comment
to the GLUE WG list.

In parallel, Ilya Saverchenko and his colleagues from LRZ are pushing
forward the SQL rendering and document. The LDAP rendering is in
production since few months already and the specification needs to be
read for consistency (action being carried out by Adrian Taga). We are
therefore in a good shape to move all the three rendering to last call
in the coming few weeks (hopefully before the end of April) and start
the public comment phase.

As a side news, I'd like to announce that:
- the new official source code repository is now hosted in github.com.
I have created three repositories (one per rendering) which you can
access following this link: https://github.com/OGF-GLUE/
- the descriptive documents accompanying the renderings are available
here (with the new draft for the XSD):
http://forge.ogf.org/sf/go/projects.glue-wg/docman.root.drafts
- the wiki pages have been polished and updated:
http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/HomePage

Looking forward to writing soon about when all the three specs and
documents are ready for last call. Meanwhile, if you are building on
top of GLUE XSD, you are welcome to download the new version for early
feedback.


Kind regards, Sergio


-- 
Sergio Andreozzi - Policy Development Manager
EGI.eu - Amsterdam - The Netherlands - http://egi.eu
_______________________________________________
glue-wg mailing list
glue-wg at ogf.org
http://www.ogf.org/mailman/listinfo/glue-wg


More information about the glue-wg mailing list