XSD aligned to draft 27
Dear all, I've just committed a new draft version of the XML Schema rendering for GLUE 2.0 aligned to draft 2.0. This incorporate the decisions from OGF as regards the change in the design of the associations (see the example). The auxiliaries entities have been added as well. XSD for GLUE 2.0 - draft 27 http://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/glue/xml/schema/GLUE2.xsd?rev=1344&root=omii-europe&view=log XML doc example http://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/glue/xml/examples/AdminDomain_CNAF.xml?rev=1344&root=omii-europe&view=log for Felix, please, try to update your Storage document example with this version so that we can discuss it either on Friday or Monday. Cheers, Sergio -- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi
Hi Sergio, On Wednesday 12 March 2008 19:48:31 Sergio Andreozzi wrote:
XSD for GLUE 2.0 - draft 27 http://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/glue/xml/schema/GLUE2. xsd?rev=1344&root=omii-europe&view=log
From a quick look, I spotted that the XSD defines a namespace: xmlns:glue="http://GLUE2" To my mind, this is broken: it should be a URI with FQDN + path. The path should include the year and/or a version number, allowing some version control. On a related note, we were going to discuss the XML binding with regard to primary documents; but, I don't believe this discussion took place. Discussing GLUE-2.0 "abstract" (independent of any binding) has taken priority. My concern was that, with the current binding, all valid documents are required to express the complete GLUE hierarchy. The current XSD expresses this by requiring documents have a "Grid" top-level element to be valid. This requirement does not come from XML and XSD. Moreover, I believe that, by GLUE-2.0/XML introducing this requirement, an unnecessary burden will be placed on the info-providers. This will make implementing them harder, require explicit configuration and so make the process needlessly more fragile. It would also prevents the information being published into more than one GLUE-based information system. As a specific proposal, I suggest that other elements be allowed as top-level elements; for example, that a StorageService be a valid top-level element. The primary document from a StorageService info-provider should have a StorageService as its top-level element. i.e., just added: <element name="StorageService" type="glue:StorageService_t"/> after the Grid one, near the beginning of the XSD. Cheers, Paul.
Paul, I'm less familiar with the XML terminology you use, but I would second your suggestion using commoner terminology: we should be able to independently publish subsets of the GLUE schema hierarchy. The ability to develop and run independent info-providers for subsets of information is a very useful design. Did I understand your proposal correctly? One question this raises is how one binds or links these separately published subset documents to each other? Would we need to introduce attributes in each subset that binds it to other related subsets? JP Navarro On Mar 13, 2008, at 8:51 AM, Paul Millar wrote:
Hi Sergio,
On Wednesday 12 March 2008 19:48:31 Sergio Andreozzi wrote:
XSD for GLUE 2.0 - draft 27 http://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/glue/xml/ schema/GLUE2. xsd?rev=1344&root=omii-europe&view=log
From a quick look, I spotted that the XSD defines a namespace: xmlns:glue="http://GLUE2"
To my mind, this is broken: it should be a URI with FQDN + path. The path should include the year and/or a version number, allowing some version control.
On a related note, we were going to discuss the XML binding with regard to primary documents; but, I don't believe this discussion took place. Discussing GLUE-2.0 "abstract" (independent of any binding) has taken priority.
My concern was that, with the current binding, all valid documents are required to express the complete GLUE hierarchy. The current XSD expresses this by requiring documents have a "Grid" top-level element to be valid.
This requirement does not come from XML and XSD. Moreover, I believe that, by GLUE-2.0/XML introducing this requirement, an unnecessary burden will be placed on the info-providers. This will make implementing them harder, require explicit configuration and so make the process needlessly more fragile.
It would also prevents the information being published into more than one GLUE-based information system.
As a specific proposal, I suggest that other elements be allowed as top-level elements; for example, that a StorageService be a valid top-level element. The primary document from a StorageService info-provider should have a StorageService as its top-level element.
i.e., just added:
<element name="StorageService" type="glue:StorageService_t"/>
after the Grid one, near the beginning of the XSD.
Cheers,
Paul.
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Hi JP, On Thursday 13 March 2008 15:52:56 JP Navarro wrote:
I'm less familiar with the XML terminology you use, but I would second your suggestion using commoner terminology: we should be able to independently publish subsets of the GLUE schema hierarchy. The ability to develop and run independent info-providers for subsets of information is a very useful design. Did I understand your proposal correctly?
More or less. What I would like to avoid is that storage service infoProviders publish information like: <Grid> <AdminDomain> <AdminDomain> <StorageService> <ImplementationName>foo</ImplementationName> <ImplementationVersion>1.0</ImplementationVersion> <!-- ...etc... --> </StorageService> </AdminDomain> </AdminDomain> </Grid> as this requires the SE publisher to know it's part of a distributed Tier-2 site (hence the two levels of AdminDomain elements). That said, the current XSD doesn't seem to support nested AdminDomain elements, which would be needed to describe distributed sites. An alternative would be for the SE to publish information like: <StorageService> <ImplementationName>foo</ImplementationName> <ImplementationVersion>1.0</ImplementationVersion> <!-- ...etc... --> </StorageService> and have the (site-level) aggregation happen at the site level, which would publish information like: <AdminDomain> <Name>Example Site</Name> <Services> <ComputingService> <!-- CE information goes here --> </ComputingService> <StorageService> <ImplementationName>foo</ImplementationName> <ImplementationVersion>1.0</ImplementationVersion> <!-- ...etc... --> </StorageService> </Services> </AdminDomain> The final aggregation would encapsulate multiple sites within a Grid element. <Grid> <AdminDomain> <!-- Site 1 info --> </AdminDomain> <AdminDomain> <!-- Site 2 info --> </AdminDomain> </Grid> The disadvantage of this approach is one cannot query the primary SE info (the XML provided by the SE info provider) with exactly the same query one would use when querying top-level aggregation. For example, to extract all StorageEndpoints for site Example Site, one could use the XPath: /Grid/**/AdminDomain[Name='Example Site']/Services/StorageService/StorageEndpoint Something like: <xsl:styleshet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:variable name="href" select="http://glue.example.org/grid-glue"/> <xsl:variable name="site" select = "Example Site"/> <xsl:template match="/"> <xsl:copy-of select="document($href)/Grid/**/AdminDomain[Name=$site]/Services/StorageService/StorageEndpoint"/> </xsl:template> </xsl:stylesheet> But, if one substituted the URI of the primary information (via the href variable), this particular query wouldn't work: the primary XML would not have the Grid and all AdminDomain elements. I don't think this is a big deal, though: it makes sense that that query should return no replies when querying the SE info-provider directly, and there are other queries that would work (e.g., select all StorageEndpoints) The advantage to publish with StorageService as the top-level element is that the SE info-provider need know nothing about the above Glue hierarchy. This (should) simplify the info-provider and, at the same time, allow the same information to be (easily) published under different GLUE hierarchies. For example, if a site is a member of more than one Grid. To me, this advantage outweighs the disadvantage.
One question this raises is how one binds or links these separately published subset documents to each other? Would we need to introduce attributes in each subset that binds it to other related subsets?
I believe that, currently, how the documents are merged isn't defined. One approach is to use XSLT to do the merging. There's a (working) toy implementation that demonstrates that here: http://www.ogf.org/pipermail/glue-wg/2007-December/000249.html HTH, Paul.
On Wednesday 12 March 2008 19:48:31 Sergio Andreozzi wrote: [...]
XSD for GLUE 2.0 - draft 27 http://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/glue/xml/schema/GLUE2. xsd?rev=1344&root=omii-europe&view=log
I've placed an HTML rendering (using xs3p) of the XSD here: http://www.desy.de/~paul/GLUE/GLUE2.html (It's navigable, allowing subsumption navigation (super-/sub-class) and shows XML instance representation for each element.) HTH, Paul.
participants (3)
-
JP Navarro -
Paul Millar -
Sergio Andreozzi