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@ogf.org [mailto:glue-wg-bounces@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@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg