The main aim for the GLUE session at OGF 28 was to provide a status update on the GLUE 2.0 renderings. The first part of the session was comprised of a number of presentations giving the status of the LDAP and XML renderings. The second part was a free-from discussion on the status and the next steps. It was noticed that we could have spent more time discussing various topics, so for the next OGF we may want to consider two sessions rather than just one. A nice surprise was to find out that D-Grid have implemented a portal using the GLUE 2.0 data model. It was suggested that we should maintain a collection of projects using the GLUE 2.0 model. As concrete outcomes, it was decided that we need to push forward with rendering documents with the aim of finalizing them soon. The LDAP rendering document is in good shape and should not take to much effort to finish. For the XML renderings, Balazs will arrange some phone meetings in order to discuss the outstanding issues. The question of whether or not we need an SQL rendering was raised. Although many people are putting GLUE 2.0 information into relational databases, is there a need to standardize the model? Slides from the session can be found at the following location. http://forge.gridforum.org/sf/docman/do/listDocuments/projects.glue-wg/docma... Laurence
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field said: whether or not we need an SQL rendering was raised. Although many people are putting GLUE 2.0 information into relational databases, is there a need to standardize the model?
Even if it isn't standardised it would be a good thing to document any rendering that gets implemented so any subsequent implementation has something to start from. Stephen -- Scanned by iCritical.
It would be good to standardize it then conversion between renderings only needs to be done once. It also encourages the discussion on what is the "best" way to do the SQL rendering. It may be that we have two - one with a large number of tables to handle the relationships and one where many of the relationships are pushed into one table. Which way was it done for GLUE 1? Steve On 22 March 2010 11:27, <stephen.burke@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field said: whether or not we need an SQL rendering was raised. Although many people are putting GLUE 2.0 information into relational databases, is there a need to standardize the model?
Even if it isn't standardised it would be a good thing to document any rendering that gets implemented so any subsequent implementation has something to start from.
Stephen -- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
It seems like a flat XML rendering of GLUE 2 might actually be very similar or identical in structure to a SQL rendering. If so, it would be interesting to align these two implementations of GLUE 2. JP On Mar 20, 2010, at 10:01 AM, Laurence Field wrote:
The question of whether or not we need an SQL rendering was raised. Although many people are putting GLUE 2.0 information into relational databases, is there a need to standardize the model?
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro said: It seems like a flat XML rendering of GLUE 2 might actually be very similar or identical in structure to a SQL rendering. If so, it would be interesting to align these two implementations of GLUE 2.
How do you deal with multivalued attributes and relations in xml? That's the thing which causes most difficulty in SQL, but doesn't xml just let you repeat things like LDAP? Stephen -- Scanned by iCritical.
Good point, in a relational design there might be many more tables than would be desirable even in a fairly flat XML rendering. However, I still think there a some common design considerations in a flag XML rendering that could make it into a data transport format for a relational GLUE 2 database. In other words, it is closer to a fully normalized relational design than other GLUE 2 encodings, right? JP On Mar 22, 2010, at 9:09 AM, <stephen.burke@stfc.ac.uk> <stephen.burke@stfc.ac.uk> wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro said: It seems like a flat XML rendering of GLUE 2 might actually be very similar or identical in structure to a SQL rendering. If so, it would be interesting to align these two implementations of GLUE 2.
How do you deal with multivalued attributes and relations in xml? That's the thing which causes most difficulty in SQL, but doesn't xml just let you repeat things like LDAP?
Stephen -- Scanned by iCritical.
JP Navarro [mailto:navarro@mcs.anl.gov] said:
Good point, in a relational design there might be many more tables than would be desirable even in a fairly flat XML rendering.
However, I still think there a some common design considerations in a flag XML rendering that could make it into a data transport format for a relational GLUE 2 database. In other words, it is closer to a fully normalized relational design than other GLUE 2 encodings, right?
Actually in the way we've done it I think the LDAP implementation is probably just as close, since we've said that the LDAP DN hierarchy is just for convenience. So although in practice we will have a tree, you could in theory put all the objects in a huge flat list and it would still work (other than that Extensions have to be underneath the object they extend). To go from LDAP to SQL you would basically have to break out every multivalued attribute into a separate table. Stephen -- Scanned by iCritical.
participants (4)
-
JP Navarro -
Laurence Field -
stephen.burke＠stfc.ac.uk -
Steve Fisher