Hi, 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
Hi Weijian, The XML schema that you found reflects the version of the Glue Schema that was submitted for public comments. It still needs to be updated to reflect that final specification. I forget exactly who was taking responsibility for the XML schema however, I hope that an updated version will be available soon. Regards, Laurence Weijian Fang wrote:
Hi,
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
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-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith said:
* 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.
This sounds like what I've been suggesting for LDAP - that we should view the schema as basically a collection of independent objects linked together by embedded references, and any structure you get from the implementation (LDAP tree, XML hierarchy) is incidental. Stephen -- Scanned by iCritical.
This is the same approach that has been taken for the LDAP implementation. To make this possible, IDs must be globally unique. I support this approach as it lets the implementation to be less coupled to the technology used and facilitates interaction between different systems. On Thu, Apr 23, 2009 at 10:52 AM, Burke, S (Stephen) < stephen.burke@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith said:
* 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.
This sounds like what I've been suggesting for LDAP - that we should view the schema as basically a collection of independent objects linked together by embedded references, and any structure you get from the implementation (LDAP tree, XML hierarchy) is incidental.
Stephen -- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Professional Web: http://cern.ch/horat Personal Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat
hi, David Horat wrote:
This is the same approach that has been taken for the LDAP implementation. To make this possible, IDs must be globally unique. I support this approach as it lets the implementation to be less coupled to the technology used and facilitates interaction between different systems.
we'd be rather careful going this way. in the past within nordugrid we found a common, agreed structure (at that time within nordugrid) very important. i have doubts that flattening everything will give us better interoperability. in any case, the issue/proposal worth to be discussed on a phonecall. one more note: the rendering was an important part of the public comment specification. Turning everything upside down e.g. in xml may need glue to enter into another public comment period. cheers, Balazs Konya
Hi Balazs, As others have described, there are several design, implementation, and support advantages to a decomposed/flattened approach. With unique IDs and links between the entities, it should be fairly straightforward to compose information into a large agreed/standard rendered document. There are also discovery performance and functionality advantages and disadvantages to both approaches. It seems to me like this implementation approach doesn't contradict the GLUE2 specification since it describes the same entities, attributes, and relationships, although I think you're right that it may lead us to modify the current rendering specification to include a decomposed one. An interesting questions is whether we have to have a single XML rendering in support of interoperability or if we can support several renderings? We're already willing to accommodate XML, LDAP, and SQL renderings, so why not accommodate multiple XML renderings too? Regards, JP On Apr 24, 2009, at 8:56 AM, Balazs Konya wrote:
hi,
David Horat wrote:
This is the same approach that has been taken for the LDAP implementation. To make this possible, IDs must be globally unique. I support this approach as it lets the implementation to be less coupled to the technology used and facilitates interaction between different systems.
we'd be rather careful going this way. in the past within nordugrid we found a common, agreed structure (at that time within nordugrid) very important.
i have doubts that flattening everything will give us better interoperability.
in any case, the issue/proposal worth to be discussed on a phonecall.
one more note: the rendering was an important part of the public comment specification. Turning everything upside down e.g. in xml may need glue to enter into another public comment period.
cheers, Balazs Konya _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Another interesting and useful characteristic of a flattened XML rendering is that it's conceptually SQL tables and relationships rendered in XML. The various XML elements should correspond to GLUE 2 SQL tables, and the linkages between the XML elements should correspond to SQL foreign key references. An intriguing way to pull all of these ideas together would be to develop a REST compliant URL interface for accessing GLUE 2 information, where that interface accesses information in a SQL rendering OR a flattened XML rendering of GLUE 2. That native SQL or flattened XML content can be returned to clients as CSV, XML, JSON, or other formats back to the REST client. Client request -> GLUE 2 REST ---> GLUE 2 SQL or flattened XML repository Client response is CSV, XML, JSON, or other rendering of repository GLUE 2 JP On Apr 24, 2009, at 9:21 AM, JP Navarro wrote:
Hi Balazs,
As others have described, there are several design, implementation, and support advantages to a decomposed/flattened approach. With unique IDs and links between the entities, it should be fairly straightforward to compose information into a large agreed/standard rendered document.
There are also discovery performance and functionality advantages and disadvantages to both approaches.
It seems to me like this implementation approach doesn't contradict the GLUE2 specification since it describes the same entities, attributes, and relationships, although I think you're right that it may lead us to modify the current rendering specification to include a decomposed one. An interesting questions is whether we have to have a single XML rendering in support of interoperability or if we can support several renderings? We're already willing to accommodate XML, LDAP, and SQL renderings, so why not accommodate multiple XML renderings too?
Regards,
JP On Apr 24, 2009, at 8:56 AM, Balazs Konya wrote:
hi,
David Horat wrote:
This is the same approach that has been taken for the LDAP implementation. To make this possible, IDs must be globally unique. I support this approach as it lets the implementation to be less coupled to the technology used and facilitates interaction between different systems.
we'd be rather careful going this way. in the past within nordugrid we found a common, agreed structure (at that time within nordugrid) very important.
i have doubts that flattening everything will give us better interoperability.
in any case, the issue/proposal worth to be discussed on a phonecall.
one more note: the rendering was an important part of the public comment specification. Turning everything upside down e.g. in xml may need glue to enter into another public comment period.
cheers, Balazs Konya _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
A few comments. On Tue, Jun 2, 2009 at 3:54 PM, JP Navarro <navarro@mcs.anl.gov> wrote:
Another interesting and useful characteristic of a flattened XML rendering is that it's conceptually SQL tables and relationships rendered in XML.
The various XML elements should correspond to GLUE 2 SQL tables, and the linkages between the XML elements should correspond to SQL foreign key references.
I also think it would be easier to map. I would strongly suggest to enforce the implementation of all relations in the XML in the way of Foreign Keys, as what we have done with LDAP. Appart from that, you can also choose to use a concrete tree or not, but at least you know you can navigate using a common way: Foreign Keys.
An intriguing way to pull all of these ideas together would be to develop a REST compliant URL interface for accessing GLUE 2 information, where that interface accesses information in a SQL rendering OR a flattened XML rendering of GLUE 2. That native SQL or flattened XML content can be returned to clients as CSV, XML, JSON, or other formats back to the REST client.
The XML output is what it will also be covered by the XML rendering. For other renderings, such as CSV of JSON we will have to make separated documents. Anyway, I think that with XML should be enough at the moment.
Client request -> GLUE 2 REST ---> GLUE 2 SQL or flattened XML repository Client response is CSV, XML, JSON, or other rendering of repository GLUE 2
JP
On Apr 24, 2009, at 9:21 AM, JP Navarro wrote:
Hi Balazs,
As others have described, there are several design, implementation, and support advantages to a decomposed/flattened approach. With unique IDs and links between the entities, it should be fairly straightforward to compose information into a large agreed/standard rendered document.
There are also discovery performance and functionality advantages and disadvantages to both approaches.
It seems to me like this implementation approach doesn't contradict the GLUE2 specification since it describes the same entities, attributes, and relationships, although I think you're right that it may lead us to modify the current rendering specification to include a decomposed one. An interesting questions is whether we have to have a single XML rendering in support of interoperability or if we can support several renderings? We're already willing to accommodate XML, LDAP, and SQL renderings, so why not accommodate multiple XML renderings too?
Regards,
JP On Apr 24, 2009, at 8:56 AM, Balazs Konya wrote:
hi,
David Horat wrote:
This is the same approach that has been taken for the LDAP implementation. To make this possible, IDs must be globally unique. I support this approach as it lets the implementation to be less coupled to the technology used and facilitates interaction between different systems.
we'd be rather careful going this way. in the past within nordugrid we found a common, agreed structure (at that time within nordugrid) very important.
i have doubts that flattening everything will give us better interoperability.
in any case, the issue/proposal worth to be discussed on a phonecall.
one more note: the rendering was an important part of the public comment specification. Turning everything upside down e.g. in xml may need glue to enter into another public comment period.
cheers, Balazs Konya _______________________________________________ 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
-- David Horat Software Engineer – IT/GD – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Address: 1211 Geneva - Switzerland, Office: 28/R-003 Phone +41 22 76 77996 Fax +41 22 76 68178 (fax to email service) Web: http://cern.ch/horat Web: http://davidhorat.com/ Profile: http://linkedin.com/in/davidhorat
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
participants (9)
-
Balazs Konya -
Burke, S (Stephen) -
David Horat -
JP Navarro -
Laurence Field -
Sergio Andreozzi -
Sergio＠CNAF
-
Warren Smith -
Weijian Fang