OGF 35 meeting and preparation reminder
Dear GLUE WG, Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time. http://ogf.org/gf/event_schedule/index.php?id=2530 Our agenda: i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc. Recent action items to prepare for this meeting: Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP We will post meeting call-in information when it's available. Regards, JP
Dear all, On 2012-06-13 12:02, JP Navarro wrote:
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Futuredirections discussion: JSON rendering, etc.
I'd like to propose two more agenda items: 1) GLUE2 Rendering document drafts status and short term glue-wg actions to move forward to be able to start the OGF document release process (public comments, so on) Now it is really time to officially release something as an OGF GLUE2 rendering for xml, ldap, relational. It is nice to discuss new extensions, future directions but i believe the glue group's main priority right now should be the completion of the rendering work. That is dragging on for years now. 2) LDAP rendering document draft: Feedback from NorduGrid/ARC In Lund we thoroughly reviewed the old ldap rendering draft from the ARC implementation point of view and prepared a revised version with lots of (tracked) changes and comments (to be uploaded to the gridforge soon). We'd like to present our feedback on the LDAP rendering draft in 15 minutes. Unfortunately, i wont' be able to attend the OGF session but Florido Paganelli will be there to give the presentation. regards, Balazs Konya -- Balázs Kónya Technical Director European Middleware Initiative www.eu-emi.eu NorduGrid Collaboration www.nordugrid.org Lund University balazs.konya@hep.lu.se Institute of Physics, EHEP phone: +46 46 222 8049 BOX 118, S - 221 00 LUND, Sweden fax: +46 46 222 4015
On Wed, Jun 13, 2012 at 1:51 PM, Balazs Konya <balazs.konya@hep.lu.se> wrote:
It is nice to discuss new extensions, future directions but i believe the glue group's main priority right now should be the completion of the rendering work. That is dragging on for years now.
+1 Cheers, Andre. -- Nothing is ever easy...
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Balazs Konya said: Unfortunately, i wont' be able to attend the OGF session but Florido Paganelli will be there to give the presentation.
I won't be in Delft, but I should be able to join as long as remote access is available. Stephen -- Scanned by iCritical.
Hi everyone, Regarding the XML rendering: for me the most important agenda item is to make a decision between the flattened document style (e.g. like the Teragrid rendering), or a nested/hierarchical approach (the current style described in the word doc), or somewhere between. Both styles render associations using their own 'identifier' elements that reference the IDs of associated elements. Until last phone meeting, I had not seen the Teragrid rendering which looks good to me. This approach may be preferable compared to defining deeply nested element trees. Therefore, I think the agenda item iii) needs to come first before the substitution group stuff. Regardless of the preferred style, I still think we need to cater for sub-typing of the core entities by future profiles at the outset. I am pretty sure the abstract-element/substitution group approach may also be useful to the flattened style. For example, maybe the global 'Entities' element could define abstract elements such as 'AbstractService' so that concrete specialisations can be substituted in place (e.g. Service, ComputingService, StorageService and potentially any future profiled service that can substitute for AbstractService). Same sort of thing could apply to abstract Domain and AdminDomain/UserDomain etc. Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 13 June 2012 11:02 To: OGF GLUE WG Subject: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc.
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP
We will post meeting call-in information when it's available.
Regards,
JP _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.
I've been meaning to follow up our last conference call with an email about the "style" of the XML rendering. You all probably know that I prefer the flat style over the hierarchical. The current hybrid schema is a compromise between these two approaches (I think it's great that people are willing to compromise, btw), but what I mentioned on the call is that I think I prefer the flat (https://github.com/OGF-GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd) or hierarchical (https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue-wg/docman....) styles to the hybrid (https://github.com/OGF-GLUE/XSD/blob/master/schema/GLUE2.xsd) one. I've seen a couple of comments that make me wonder if I'm not alone in this. One of the high-level concern that I have with the hybrid approach is that a GLUE2 entity can appear in several different places in a GLUE2 document (this is why it is a hybrid approach, of course). For example, a document could only have a ComputingActivity, it could be ComputingActivities -> ComputingActivity, or ComputingEndpoint -> ComputingActivities -> ComputingActivity. As was mentioned on the call, you can search the document for that element name, but that seems a bit inelegant to me and implies that the hierarchical structure of the document doesn't even matter. Another high-level concern is linking of entities. The hierarchical approach linked many entities via parent-child in the XML hierarchy. A flat approach links them using IDs to refer to each other. With a hybrid approach something like both of these need to be supported and this seems a bit confusing - the ID references will be in the schema, but only needed if a particular XML document doesn't use a hierarchy. This could lead to confusion when creating/parsing documents. I have some other comments about the current hybrid schema, but I'll send separate emails about those. Do we need a discussion about these three different styles? There seems to be an assumption that there is agreement on the compromise hybrid style, but I'm not sure that is the case... Warren -----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk Sent: Wednesday, June 13, 2012 11:14 AM To: navarro@mcs.anl.gov; glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder Hi everyone, Regarding the XML rendering: for me the most important agenda item is to make a decision between the flattened document style (e.g. like the Teragrid rendering), or a nested/hierarchical approach (the current style described in the word doc), or somewhere between. Both styles render associations using their own 'identifier' elements that reference the IDs of associated elements. Until last phone meeting, I had not seen the Teragrid rendering which looks good to me. This approach may be preferable compared to defining deeply nested element trees. Therefore, I think the agenda item iii) needs to come first before the substitution group stuff. Regardless of the preferred style, I still think we need to cater for sub-typing of the core entities by future profiles at the outset. I am pretty sure the abstract-element/substitution group approach may also be useful to the flattened style. For example, maybe the global 'Entities' element could define abstract elements such as 'AbstractService' so that concrete specialisations can be substituted in place (e.g. Service, ComputingService, StorageService and potentially any future profiled service that can substitute for AbstractService). Same sort of thing could apply to abstract Domain and AdminDomain/UserDomain etc. Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 13 June 2012 11:02 To: OGF GLUE WG Subject: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc.
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP
We will post meeting call-in information when it's available.
Regards,
JP _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.
glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
I would vote for flat. Steve On 14 June 2012 11:56, Warren Smith <wsmith@tacc.utexas.edu> wrote:
I've been meaning to follow up our last conference call with an email about the "style" of the XML rendering. You all probably know that I prefer the flat style over the hierarchical. The current hybrid schema is a compromise between these two approaches (I think it's great that people are willing to compromise, btw), but what I mentioned on the call is that I think I prefer the flat (https://github.com/OGF-GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd) or hierarchical (https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue-wg/docman....) styles to the hybrid (https://github.com/OGF-GLUE/XSD/blob/master/schema/GLUE2.xsd) one. I've seen a couple of comments that make me wonder if I'm not alone in this.
One of the high-level concern that I have with the hybrid approach is that a GLUE2 entity can appear in several different places in a GLUE2 document (this is why it is a hybrid approach, of course). For example, a document could only have a ComputingActivity, it could be ComputingActivities -> ComputingActivity, or ComputingEndpoint -> ComputingActivities -> ComputingActivity. As was mentioned on the call, you can search the document for that element name, but that seems a bit inelegant to me and implies that the hierarchical structure of the document doesn't even matter.
Another high-level concern is linking of entities. The hierarchical approach linked many entities via parent-child in the XML hierarchy. A flat approach links them using IDs to refer to each other. With a hybrid approach something like both of these need to be supported and this seems a bit confusing - the ID references will be in the schema, but only needed if a particular XML document doesn't use a hierarchy. This could lead to confusion when creating/parsing documents.
I have some other comments about the current hybrid schema, but I'll send separate emails about those.
Do we need a discussion about these three different styles? There seems to be an assumption that there is agreement on the compromise hybrid style, but I'm not sure that is the case...
Warren
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk Sent: Wednesday, June 13, 2012 11:14 AM To: navarro@mcs.anl.gov; glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Hi everyone, Regarding the XML rendering: for me the most important agenda item is to make a decision between the flattened document style (e.g. like the Teragrid rendering), or a nested/hierarchical approach (the current style described in the word doc), or somewhere between. Both styles render associations using their own 'identifier' elements that reference the IDs of associated elements.
Until last phone meeting, I had not seen the Teragrid rendering which looks good to me. This approach may be preferable compared to defining deeply nested element trees. Therefore, I think the agenda item iii) needs to come first before the substitution group stuff.
Regardless of the preferred style, I still think we need to cater for sub-typing of the core entities by future profiles at the outset. I am pretty sure the abstract-element/substitution group approach may also be useful to the flattened style. For example, maybe the global 'Entities' element could define abstract elements such as 'AbstractService' so that concrete specialisations can be substituted in place (e.g. Service, ComputingService, StorageService and potentially any future profiled service that can substitute for AbstractService). Same sort of thing could apply to abstract Domain and AdminDomain/UserDomain etc.
Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 13 June 2012 11:02 To: OGF GLUE WG Subject: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc.
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP
We will post meeting call-in information when it's available.
Regards,
JP _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.
glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
Hi Warren,
I've seen a couple of comments that make me wonder if I'm not alone in this.
Yes, after being introduced to your schema in the last WG meeting I think the flattened style may be preferable, especially for rendering GLUE entities that can exist standalone and have their own lifetime that is not tied to an associated/parent entity, i.e. a weak dependency as defined by UML Aggregation/Association (note, a fully exploded/fully flattened structure may not always be appropriate for rendering those elements whose lifetime is strictly tied to their associated element/parent, i.e UML Composition). Another example that I think illustrates your point (below) is that a single Service could potentially be a member of two AdminDomainS (perhaps not common but it's possible). For example in GOCDB, a single Service instance may be hosted by a both a physical site (which correlates to an AdminDomain) and a virtual site (which would also correlate to an AdminDomain). Given the nested approach, one AdminDomain would need to nest this service and the other AdminDomain would either need to back-reference the nested service or define a duplicate. Couple of possible suggestions/thoughts for the meeting: 1) I think the core entities should be importable for use in other 3rd party schema files. This would require them being made global. I realise that this would create more global elements other than the Entities element, but this is normal in my experience in XSD. It can be clearly documented that the 'Entities' element is the intended document root. 2) I also think that abstract/substitution group concept may also be applicable so that profiles can define sub-type specialisations in future (e.g. new services types) and subsequently nest those specialisations within 'Entities' without having to modify the original XSD Entities element. Unfortunately I'll not be able to attend the meeting in Delft in person, but I will aim to skype in. Cheers, David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith Sent: 14 June 2012 11:57 To: glue-wg@ogf.org Subject: [glue-wg] XML rendering style
I've been meaning to follow up our last conference call with an email about the "style" of the XML rendering. You all probably know that I prefer the flat style over the hierarchical. The current hybrid schema is a compromise between these two approaches (I think it's great that people are willing to compromise, btw), but what I mentioned on the call is that I think I prefer the flat (https://github.com/OGF- GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd) or hierarchical (https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue- wg/docman.root.drafts/doc15515) styles to the hybrid (https://github.com/OGF- GLUE/XSD/blob/master/schema/GLUE2.xsd) one. I've seen a couple of comments that make me wonder if I'm not alone in this.
One of the high-level concern that I have with the hybrid approach is that a GLUE2 entity can appear in several different places in a GLUE2 document (this is why it is a hybrid approach, of course). For example, a document could only have a ComputingActivity, it could be ComputingActivities -> ComputingActivity, or ComputingEndpoint -> ComputingActivities -> ComputingActivity. As was mentioned on the call, you can search the document for that element name, but that seems a bit inelegant to me and implies that the hierarchical structure of the document doesn't even matter.
Another high-level concern is linking of entities. The hierarchical approach linked many entities via parent-child in the XML hierarchy. A flat approach links them using IDs to refer to each other. With a hybrid approach something like both of these need to be supported and this seems a bit confusing - the ID references will be in the schema, but only needed if a particular XML document doesn't use a hierarchy. This could lead to confusion when creating/parsing documents.
I have some other comments about the current hybrid schema, but I'll send separate emails about those.
Do we need a discussion about these three different styles? There seems to be an assumption that there is agreement on the compromise hybrid style, but I'm not sure that is the case...
Warren
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk Sent: Wednesday, June 13, 2012 11:14 AM To: navarro@mcs.anl.gov; glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Hi everyone, Regarding the XML rendering: for me the most important agenda item is to make a decision between the flattened document style (e.g. like the Teragrid rendering), or a nested/hierarchical approach (the current style described in the word doc), or somewhere between. Both styles render associations using their own 'identifier' elements that reference the IDs of associated elements.
Until last phone meeting, I had not seen the Teragrid rendering which looks good to me. This approach may be preferable compared to defining deeply nested element trees. Therefore, I think the agenda item iii) needs to come first before the substitution group stuff.
Regardless of the preferred style, I still think we need to cater for sub- typing of the core entities by future profiles at the outset. I am pretty sure the abstract-element/substitution group approach may also be useful to the flattened style. For example, maybe the global 'Entities' element could define abstract elements such as 'AbstractService' so that concrete specialisations can be substituted in place (e.g. Service, ComputingService, StorageService and potentially any future profiled service that can substitute for AbstractService). Same sort of thing could apply to abstract Domain and AdminDomain/UserDomain etc.
Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 13 June 2012 11:02 To: OGF GLUE WG Subject: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc.
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP
We will post meeting call-in information when it's available.
Regards,
JP _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.
glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of david.meredith@stfc.ac.uk said: Yes, after being introduced to your schema in the last WG meeting I think the flattened style may be preferable, especially for rendering GLUE entities that can exist standalone and have their own lifetime that is not tied to an associated/parent entity,
Some objects may simply not be published by a given information provider - for example if an implementation publishes Datastore objects but not StorageManager you may have a problem if Datastore is required to be a child of StorageManager. For the LDAP rendering we made the objects self-contained - all references can be followed either by querying for an ID or a ForeignKey. If objects don't exist then references may not resolve but it isn't intrinsically inconsistent. Stephen -- Scanned by iCritical.
Warren, Steve, David and all OGF GLUE members, Concerning the hierarchical versus flat renderings, I consider that : - The GLUE 2 schema itself does NOT define any hierarchy. So, different stakeholders necessarily have different preferences for the hierarchy (for example, is the placement of 'Activity' at the top of the hierarchy any more stupid than any other class ?). Therefore, I doubt on the possibility of a worldwide agreement on any hierarchical rendering. Besides, any hierarchical rendering will stuck when entities whose class was previously supposed to be only 'child' will come up with relationships with more than 1 entity whose class was previously supposed to be only 'father'. - The distributed infrastructure covered by the GLUE 2 schema is NOT managed along a strict hierarchy, but the publication of entity attributes towards the Information System tends to be performed locally by the entity itself, WITHOUT any knowledge of the entity which is considered 'father' by some hierarchical rendering. - For security, Information Systems must be able to publish subsets of the entities and attributes depending NOT on any predefined hierarchy, but depending dynamically on the requester credentials, - User queries on the Information Systems do NOT follow a strict hierarchy, but tend to be ANY retrieval of attributes of entities of a first class linked in ANY relevant way to entities of a second class having given values for some attributes (think of SQL queries using ANY (number of) legal table joins). Therefore, hierarchical renderings need to provide references to ALL related entities whose class is NOT a direct parent or child. This ends up with almost as many references than in a flat model, and requires the SAME BURDEN of validation of reference consistency than any flat model. In conclusion, like Warren, Steve and David, I vote for flat renderings, as well using XML as JSON. Like David, I'll not be able to attend the meeting in Delft in person, but I will aim to skype in. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Thu, 14/06/2012 17:15, david.meredith@stfc.ac.uk wrote:
Hi Warren,
I've seen a couple of comments that make me wonder if I'm not alone in this.
Yes, after being introduced to your schema in the last WG meeting I think the flattened style may be preferable, especially for rendering GLUE entities that can exist standalone and have their own lifetime that is not tied to an associated/parent entity, i.e. a weak dependency as defined by UML Aggregation/Association (note, a fully exploded/fully flattened structure may not always be appropriate for rendering those elements whose lifetime is strictly tied to their associated element/parent, i.e UML Composition).
Another example that I think illustrates your point (below) is that a single Service could potentially be a member of two AdminDomainS (perhaps not common but it's possible). For example in GOCDB, a single Service instance may be hosted by a both a physical site (which correlates to an AdminDomain) and a virtual site (which would also correlate to an AdminDomain). Given the nested approach, one AdminDomain would need to nest this service and the other AdminDomain would either need to back-reference the nested service or define a duplicate.
Couple of possible suggestions/thoughts for the meeting: 1) I think the core entities should be importable for use in other 3rd party schema files. This would require them being made global. I realise that this would create more global elements other than the Entities element, but this is normal in my experience in XSD. It can be clearly documented that the 'Entities' element is the intended document root. 2) I also think that abstract/substitution group concept may also be applicable so that profiles can define sub-type specialisations in future (e.g. new services types) and subsequently nest those specialisations within 'Entities' without having to modify the original XSD Entities element.
Unfortunately I'll not be able to attend the meeting in Delft in person, but I will aim to skype in. Cheers, David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith Sent: 14 June 2012 11:57 To: glue-wg@ogf.org Subject: [glue-wg] XML rendering style
I've been meaning to follow up our last conference call with an email about the "style" of the XML rendering. You all probably know that I prefer the flat style over the hierarchical. The current hybrid schema is a compromise between these two approaches (I think it's great that people are willing to compromise, btw), but what I mentioned on the call is that I think I prefer the flat (https://github.com/OGF- GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd) or hierarchical (https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue- wg/docman.root.drafts/doc15515) styles to the hybrid (https://github.com/OGF- GLUE/XSD/blob/master/schema/GLUE2.xsd) one. I've seen a couple of comments that make me wonder if I'm not alone in this.
One of the high-level concern that I have with the hybrid approach is that a GLUE2 entity can appear in several different places in a GLUE2 document (this is why it is a hybrid approach, of course). For example, a document could only have a ComputingActivity, it could be ComputingActivities -> ComputingActivity, or ComputingEndpoint -> ComputingActivities -> ComputingActivity. As was mentioned on the call, you can search the document for that element name, but that seems a bit inelegant to me and implies that the hierarchical structure of the document doesn't even matter.
Another high-level concern is linking of entities. The hierarchical approach linked many entities via parent-child in the XML hierarchy. A flat approach links them using IDs to refer to each other. With a hybrid approach something like both of these need to be supported and this seems a bit confusing - the ID references will be in the schema, but only needed if a particular XML document doesn't use a hierarchy. This could lead to confusion when creating/parsing documents.
I have some other comments about the current hybrid schema, but I'll send separate emails about those.
Do we need a discussion about these three different styles? There seems to be an assumption that there is agreement on the compromise hybrid style, but I'm not sure that is the case...
Warren
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk Sent: Wednesday, June 13, 2012 11:14 AM To: navarro@mcs.anl.gov; glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Hi everyone, Regarding the XML rendering: for me the most important agenda item is to make a decision between the flattened document style (e.g. like the Teragrid rendering), or a nested/hierarchical approach (the current style described in the word doc), or somewhere between. Both styles render associations using their own 'identifier' elements that reference the IDs of associated elements.
Until last phone meeting, I had not seen the Teragrid rendering which looks good to me. This approach may be preferable compared to defining deeply nested element trees. Therefore, I think the agenda item iii) needs to come first before the substitution group stuff.
Regardless of the preferred style, I still think we need to cater for sub- typing of the core entities by future profiles at the outset. I am pretty sure the abstract-element/substitution group approach may also be useful to the flattened style. For example, maybe the global 'Entities' element could define abstract elements such as 'AbstractService' so that concrete specialisations can be substituted in place (e.g. Service, ComputingService, StorageService and potentially any future profiled service that can substitute for AbstractService). Same sort of thing could apply to abstract Domain and AdminDomain/UserDomain etc.
Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 13 June 2012 11:02 To: OGF GLUE WG Subject: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc.
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP
We will post meeting call-in information when it's available.
Regards,
JP
On 06/14/2012 05:15 PM, david.meredith@stfc.ac.uk wrote:
Hi Warren,
I've seen a couple of comments that make me wonder if I'm not alone in this.
Yes, after being introduced to your schema in the last WG meeting I think the flattened style may be preferable, especially for rendering GLUE entities that can exist standalone and have their own lifetime that is not tied to an associated/parent entity, i.e. a weak dependency as defined by UML Aggregation/Association (note, a fully exploded/fully flattened structure may not always be appropriate for rendering those elements whose lifetime is strictly tied to their associated element/parent, i.e UML Composition).
Another example that I think illustrates your point (below) is that a single Service could potentially be a member of two AdminDomainS (perhaps not common but it's possible).
If this errata makes sense https://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE20Errata "In the GLUE Specification v. 2.0, page 11, the relationship AdminDomain-Service in AdminDomain has not a counterpart in Service (page 13). Service object should have a relation to AdminDomain with multiplicity 1." Then is not possible for a Service to belong to multiple AdminDomains. I asked this question myself and I believe it would make sense to have multiplicity >= 0, but then it should be clear that there is no correspondence between the old glue1 concept of "site" and the GLUE2 concept of domain. Furthermore the UML model seems to say that the association between Service and AdminDomain is an aggregation without multiplicity on the endings, but * multiplicity on the association. So in principle a Service can "live" without a Domain and can even have more than one. Anybody remembers why such a strong multiplicity in the errata? I believe this is only due to the old glue1 site concept. Or it's just that the errata is not valid? Cheers, Florido
For example in GOCDB, a single Service instance may be hosted by a both a physical site (which correlates to an AdminDomain) and a virtual site (which would also correlate to an AdminDomain). Given the nested approach, one AdminDomain would need to nest this service and the other AdminDomain would either need to back-reference the nested service or define a duplicate.
Couple of possible suggestions/thoughts for the meeting: 1) I think the core entities should be importable for use in other 3rd party schema files. This would require them being made global. I realise that this would create more global elements other than the Entities element, but this is normal in my experience in XSD. It can be clearly documented that the 'Entities' element is the intended document root. 2) I also think that abstract/substitution group concept may also be applicable so that profiles can define sub-type specialisations in future (e.g. new services types) and subsequently nest those specialisations within 'Entities' without having to modify the original XSD Entities element.
Unfortunately I'll not be able to attend the meeting in Delft in person, but I will aim to skype in. Cheers, David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith Sent: 14 June 2012 11:57 To: glue-wg@ogf.org Subject: [glue-wg] XML rendering style
I've been meaning to follow up our last conference call with an email about the "style" of the XML rendering. You all probably know that I prefer the flat style over the hierarchical. The current hybrid schema is a compromise between these two approaches (I think it's great that people are willing to compromise, btw), but what I mentioned on the call is that I think I prefer the flat (https://github.com/OGF- GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd) or hierarchical (https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue-
wg/docman.root.drafts/doc15515) styles to the hybrid (https://github.com/OGF-
GLUE/XSD/blob/master/schema/GLUE2.xsd) one. I've seen a couple of comments that make me wonder if I'm not alone in this.
One of the high-level concern that I have with the hybrid approach is that a GLUE2 entity can appear in several different places in a GLUE2 document (this is why it is a hybrid approach, of course). For example, a document could only have a ComputingActivity, it could be ComputingActivities -> ComputingActivity, or ComputingEndpoint -> ComputingActivities -> ComputingActivity. As was mentioned on the call, you can search the document for that element name, but that seems a bit inelegant to me and implies that the hierarchical structure of the document doesn't even matter.
Another high-level concern is linking of entities. The hierarchical approach linked many entities via parent-child in the XML hierarchy. A flat approach links them using IDs to refer to each other. With a hybrid approach something like both of these need to be supported and this seems a bit confusing - the ID references will be in the schema, but only needed if a particular XML document doesn't use a hierarchy. This could lead to confusion when creating/parsing documents.
I have some other comments about the current hybrid schema, but I'll send separate emails about those.
Do we need a discussion about these three different styles? There seems to be an assumption that there is agreement on the compromise hybrid style, but I'm not sure that is the case...
Warren
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk Sent: Wednesday, June 13, 2012 11:14 AM To: navarro@mcs.anl.gov; glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Hi everyone, Regarding the XML rendering: for me the most important agenda item is to make a decision between the flattened document style (e.g. like the Teragrid rendering), or a nested/hierarchical approach (the current style described in the word doc), or somewhere between. Both styles render associations using their own 'identifier' elements that reference the IDs of associated elements.
Until last phone meeting, I had not seen the Teragrid rendering which looks good to me. This approach may be preferable compared to defining deeply nested element trees. Therefore, I think the agenda item iii) needs to come first before the substitution group stuff.
Regardless of the preferred style, I still think we need to cater for sub- typing of the core entities by future profiles at the outset. I am pretty sure the abstract-element/substitution group approach may also be useful to the flattened style. For example, maybe the global 'Entities' element could define abstract elements such as 'AbstractService' so that concrete specialisations can be substituted in place (e.g. Service, ComputingService, StorageService and potentially any future profiled service that can substitute for AbstractService). Same sort of thing could apply to abstract Domain and AdminDomain/UserDomain etc.
Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 13 June 2012 11:02 To: OGF GLUE WG Subject: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Just a reminder of our OGF 35 GLUE2 working group meeting this coming Sunday June 17th 13:30-15:00 Central European Time.
http://ogf.org/gf/event_schedule/index.php?id=2530
Our agenda:
i) Substitution group discussion and agreement ii) EGI service names and types discussion iii) Globalized schema and cross-references iv) Future directions discussion: JSON rendering, etc.
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP
We will post meeting call-in information when it's available.
Regards,
JP _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical. _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Florido Paganelli said: Then is not possible for a Service to belong to multiple AdminDomains.
I asked this question myself and I believe it would make sense to have multiplicity >= 0, but then it should be clear that there is no correspondence between the old glue1 concept of "site" and the GLUE2 concept of domain.
AdminDomains can be structured in a hierarchy, but the lowest level in the hierarchy does indeed correspond to a site and a Service can only belong to one site. If there's a need to represent non-tree-like relationships the ID of related AdminDomains would have to be carried in OtherInfo or Extension attributes. "Site" is not really a glue concept, it's a basic concept in the way the grid is managed in general. Stephen -- Scanned by iCritical.
Hi JP, On Wednesday 13 June 2012 12:02:05 JP Navarro wrote:
iv) Future directions discussion: JSON rendering, etc.
How serious are we with the idea of another rendering? I'm thinking of JSON in particular, which seems to pop up as a "nice to have", which I'm not sure if anyone's actively working on. The reason for asking is that within EMI there was a group (EMIR) that are working with GLUE 2.0 and, in effect, created their own JSON rendering of GLUE 2.0, although they didn't seem to realise that's what they did -- or, at least, haven't contributed it back to the GLUE WG. I think what they have developed will work for their particular use-case, but their rendering isn't well documented and (reverse engineering the format it in my head) I suspect isn't generally applicable for all the expressive power of GLUE 2.0. I've tried to encourage them to take part in a standardisation effort, but not had too much success so far. I'll keep trying. Cheers, Paul.
On 06/14/2012 08:13 AM, Paul Millar wrote:
Hi JP,
On Wednesday 13 June 2012 12:02:05 JP Navarro wrote:
iv) Future directions discussion: JSON rendering, etc. How serious are we with the idea of another rendering? I'm thinking of JSON in particular, which seems to pop up as a "nice to have", which I'm not sure if anyone's actively working on.
I think that there is a need for a JSON rendering. Laurence
I recently created a JSON rendering for a project called FutureGrid. I haven't taken the time to document it yet, but it follows the flat style of the TeraGrid XML rendering. I'd be interested in discussing a JSON rendering and once I get a chance to document what I did, I'll provide it to the group. Warren -----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field Sent: Thursday, June 14, 2012 3:34 AM To: glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder On 06/14/2012 08:13 AM, Paul Millar wrote:
Hi JP,
On Wednesday 13 June 2012 12:02:05 JP Navarro wrote:
iv) Future directions discussion: JSON rendering, etc. How serious are we with the idea of another rendering? I'm thinking of JSON in particular, which seems to pop up as a "nice to have", which I'm not sure if anyone's actively working on.
I think that there is a need for a JSON rendering. Laurence _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
On 06/14/2012 12:59 PM, Warren Smith wrote:
I recently created a JSON rendering for a project called FutureGrid. I haven't taken the time to document it yet, but it follows the flat style of the TeraGrid XML rendering. For the EMI Registry a flat structure was chosen aswell.
I'd be interested in discussing a JSON rendering and once I get a chance to document what I did, I'll provide it to the group. Agreeing on the naming rules and structure would be good.
Laurence
Great, I'll try to send a JSON example or two to the list this week. I haven't deployed this into production yet so I can easily make changes based on discussion and what others are doing. Warren -----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field Sent: Thursday, June 14, 2012 6:50 AM To: glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder On 06/14/2012 12:59 PM, Warren Smith wrote:
I recently created a JSON rendering for a project called FutureGrid. I haven't taken the time to document it yet, but it follows the flat style of the TeraGrid XML rendering. For the EMI Registry a flat structure was chosen aswell.
I'd be interested in discussing a JSON rendering and once I get a chance to document what I did, I'll provide it to the group. Agreeing on the naming rules and structure would be good.
Laurence _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Paul Millar said: The reason for asking is that within EMI there was a group (EMIR) that are working with GLUE 2.0 and, in effect, created their own JSON rendering of GLUE 2.0, although they didn't seem to realise that's what they did -- or, at least, haven't contributed it back to the GLUE WG.
There's also in effect a condor classad rendering in the WMS, based on the LDAP naming. I asked them if they have any documentation but it seems not. The LDAP naming scheme produces unique names for each attribute so it's potentially useful for any technology with a flat name space. Stephen -- Scanned by iCritical.
Dear Paul, On Thu, Jun 14, 2012 at 8:13 AM, Paul Millar <paul.millar@desy.de<mailto:paul.millar@desy.de>> wrote: Hi JP, On Wednesday 13 June 2012 12:02:05 JP Navarro wrote:
iv) Future directions discussion: JSON rendering, etc.
How serious are we with the idea of another rendering? I'm thinking of JSON in particular, which seems to pop up as a "nice to have", which I'm not sure if anyone's actively working on. The reason for asking is that within EMI there was a group (EMIR) that are working with GLUE 2.0 and, in effect, created their own JSON rendering of GLUE 2.0, although they didn't seem to realise that's what they did -- or, at least, haven't contributed it back to the GLUE WG. I think what they have developed will work for their particular use-case, but their rendering isn't well documented and (reverse engineering the format it in my head) I suspect isn't generally applicable for all the expressive power of GLUE 2.0. True, the rendering has been developed for the specific use case. The reason behind having this topic on the ogf session agenda is to introduce the EMIR(1) way of json rendering, along with discussion regarding its improviements, alternative styles (nested vs. flat), etc... (1) a service endpoint registry developed within the EMI project. http://eu-emi.github.com/emiregistry/documentation/registry-1.1.1/emir-manua... I am also summarising EMIR json rendering below for better understanding. In EMIR, the json rendering doesn't cover all the entities of the specification, but a smaller subset covering the Service and Endpoint classes. The attributes therein are flattened and separated by underscores ("_"), for example the Service ID is expressed as Service_ID and Service Endpoint ID as Service_Endpoint_ID. There are also additional attributes containing the metadata, such as lifetime, owner to control the registrations. For the successful registration, every document must define Service_Endpoint_URL (instead of the Service_Endpoint_ID), thus URL uniquely identifies documents in the collection. Off course this is not according to the GLUE 2 specification where the IDs are unique, but due to easier tracking of records (while being stored in multiple EMIR servers) we thought of URL as the meaningful handles. Again, using unique IDs is technically possible too, however the publisher has to keep track of their registrations (json documents) with the IDs instead of URLs. The link to the example json document http://eu-emi.github.com/emiregistry/documentation/registry-1.1.1/emir-manua... Since we do not have any official GLUE2 json rendering yet, having EMIR's json might be the starting point. I've tried to encourage them to take part in a standardisation effort, but not had too much success so far. I'll keep trying. I disagree, you aren't unsuccessful so far :) Best regards, Shiraz Cheers, Paul. _______________________________________________ glue-wg mailing list glue-wg@ogf.org<mailto:glue-wg@ogf.org> https://www.ogf.org/mailman/listinfo/glue-wg -- Ahmed Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Kennen Sie schon unseren neuen Film? http://www.fz-juelich.de/film Kennen Sie schon unsere app? http://www.fz-juelich.de/app
Dear GLUE WG, Based on the discussions on the list Shiraz and I propose the following revised agenda: Revised agenda: i) XML rendering (1 hour) 1) Style: hierarchical, hybrid, or flat; pros and cons; try to reach consensus and vote 2) Do we need a Global element? 3) How to implement cross-references 4) Substitution group discussion and agreement Likely action items: need someone to work on the XML rendering document and the normative XML schema ii) LDAP rendering document next steps (10 minutes) iii) EGI service names and types discussion (10 minutes) iv) Future directions discussion: JSON rendering, etc. (10 minutes) http://ogf.org/gf/event_schedule/index.php?id=2530 Recent action items to prepare for this meeting: Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP (may have been covered in e-mails already). We will post meeting call-in information when it's available. Regards, JP and Shiraz
Hi all, In prep for the meeting on Sunday. A few slides attached which completes my action. Is someone Shiraz? ok presenting these if the phone-in/skype does not work? Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 15 June 2012 14:16 To: OGF GLUE WG Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Based on the discussions on the list Shiraz and I propose the following revised agenda:
Revised agenda:
i) XML rendering (1 hour) 1) Style: hierarchical, hybrid, or flat; pros and cons; try to reach consensus and vote 2) Do we need a Global element? 3) How to implement cross-references 4) Substitution group discussion and agreement Likely action items: need someone to work on the XML rendering document and the normative XML schema ii) LDAP rendering document next steps (10 minutes) iii) EGI service names and types discussion (10 minutes) iv) Future directions discussion: JSON rendering, etc. (10 minutes)
http://ogf.org/gf/event_schedule/index.php?id=2530
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David
Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP (may have been covered in e-mails already).
We will post meeting call-in information when it's available.
Regards,
JP and Shiraz _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Scanned by iCritical.
A slightly updated version for this mornings meeting.
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk Sent: 15 June 2012 16:15 To: glue-wg@ogf.org Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Hi all, In prep for the meeting on Sunday. A few slides attached which completes my action. Is someone Shiraz? ok presenting these if the phone-in/skype does not work? Cheers David
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of JP Navarro Sent: 15 June 2012 14:16 To: OGF GLUE WG Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
Dear GLUE WG,
Based on the discussions on the list Shiraz and I propose the following revised agenda:
Revised agenda:
i) XML rendering (1 hour) 1) Style: hierarchical, hybrid, or flat; pros and cons; try to reach consensus and vote 2) Do we need a Global element? 3) How to implement cross-references 4) Substitution group discussion and agreement Likely action items: need someone to work on the XML rendering document and the normative XML schema ii) LDAP rendering document next steps (10 minutes) iii) EGI service names and types discussion (10 minutes) iv) Future directions discussion: JSON rendering, etc. (10 minutes)
http://ogf.org/gf/event_schedule/index.php?id=2530
Recent action items to prepare for this meeting:
Action Item: Provide a slide for OGF on how to implement the Glue Entities Bag high-level element, probably with example: Assigned to: David
Action Item: A slide will be presented in next OGF to explain the problem in greater detail. Assigned to: Warren, JP (may have been covered in e-mails already).
We will post meeting call-in information when it's available.
Regards,
JP and Shiraz _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Scanned by iCritical.
-- Scanned by iCritical.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of JP Navarro said: We will post meeting call-in information when it's available.
I'm guessing this probably isn't going to happen, but it would be nice if someone could confirm it ... Stephen -- Scanned by iCritical.
participants (12)
-
Andre Merzky -
Balazs Konya -
david.meredith＠stfc.ac.uk -
Etienne URBAH -
Florido Paganelli -
JP Navarro -
Laurence Field -
Paul Millar -
Shiraz Memon -
stephen.burke＠stfc.ac.uk -
Steve Fisher -
Warren Smith