Hi Warren, I'm coming back to this issue and I'd like to better clarify the rationale behind the design strategy of the XSD mapping we provided, which is described in this document: http://forge.ogf.org/sf/go/doc15514 Have a look at section 3.1.5. - we opted to reflect the natural hierarchical structure of information when possible; this simplifies query, e.g.: "I want all the information concerning a certain computing service"; this can be answered with a simple XPath expression - we require the full-hierarchy to be always present because this offers the same structure of information either if you query a primary source of information or an aggregator service; the same query will work in both situations - we enable anyway to publish fragments of info; you need to publish the hierarchy anyway and if you do not know the ID of the upper entities, you can put UNKNOWN I feel that your approach is more suitable for a back-end generation and aggregation strategy, while the above approach is more suited for exposing the info to consumers. Do you have experience in complex query from the information represented using your approach? You may want to compare it to the use case provided in this document: http://www.ogf.org/documents/GFD.137.pdf it would be useful to better understand pro and cons. Cheers, Sergio Warren Smith ha scritto:
If you'd like to see the XML Schema that I came up with for the recommendation, it is at http://software.teragrid.org/pacman/ctss4/glue2/glue2-1.0.0-r1/teragrid_glue...
Its structure is a little different from the XML Schemas from the working group. The main differences are:
* It is a flat structure with associations represented as references to the IDs of the associated entities.
* Many of the classes are included as top-level elements.
The main reason that I choose this approach was to make it easier to compose information from multiple sources. For example, I have one sensor that gathers information about jobs/activities and another that gathers information about nodes/execution environments. Plus other sensors on this system and other systems. I wanted to be able to run the sensors independently and then compose their results because the information the sensors gather changes at different time scales and the sensors can be on different systems. I felt that the composition would be easier if I avoided representing associations as sub-elements.
I also wanted the information provided by a sensor to be a valid document, so I have many classes as top-level elements. The XML Schemas from the working group only had Domains as a top-level element.
I'm not sure if folks will like or dislike these differences, but I thought I'd share them.
Warren
Sergio@CNAF wrote:
Hi Weijian,
I'm responsible for the XSD mapping together with Balazs. I had no time in the last period to work on it. The planned release date was 10 April (http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/ListOfImpleme...)
In May, we will be able to release it.
Cheers, Sergio
Weijian Fang ha scritto:
I found a GLUE2 XML schema at http://schemas.ogf.org/glue/2008/05/spec_2.0_d42_r01, but it is not very consistent with GLUE spec v. 2.0. Is there an updated one consistent with GLUE 2 conceptual model? Thanks!
Cheers,
Weijian _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg