Dear WG, For the GLUE2 XML rendering we have a design choice that I understand was also relevant in the design of the LDAP schema. Some feedback would be most helpful, especially as I understand that user requirements triggered similar changes in the LDAP schema (i.e. from style A to B as described below?) Q. In the conceptual spec, when an entity inherits associations from a super class it usually redefines the inherited associations. For example, ComputingService redefines its inherited 'Endpoint.ID' to 'ComputingEndpoint.ID.' Similarly, StorageService redefines its inherited 'Endpoint.ID' to 'StorageEndpoint.ID'. Therefore, should we reflect these redefinitions in the XML element names (or not), e.g. option A or B below? I think the strength of A is that it is made clear that a ComputingService SHOULD (or is this MUST?) reference a ComputingEndpoint. The strength of B is that queries can be more standard across different implementations (akin to polymorphic queries, .e.g. the following XPath could be used to query for all endpoint IDs from all service implementations: "/Entities/*[@BaseType='Service']/Associations/EndpointID"). There are strengths with both approaches and the decision I think has to be driven by use-case experience, hence I put this to the LDAP folks. Thanks in advance, David Option A: Redefine the associations (e.g. ComputingEndpointID, ComputingShareID) ================================================================== <ComputingService BaseType="Service"> <ID>computingService1</ID> ... <Associations> <ComputingEndpointID>computingEndpoint1</ComputingEndpointID> <ComputingShareID>someShare</ComputingShareID> </Associations> </ComputingService> Option B: Don't redefine the associations (e.g. use inherited EndpointID, ShareID) =============================================================== <ComputingService BaseType="Service"> <ID>computingService1</ID> ... <Associations> <EndpointID>computingEndpoint1</EndpointID> <ShareID>someShare</ShareID> </Associations> </ComputingService> ========================== David Meredith Scientific Computing Dept Daresbury Laboratory Tel: +44 (0) 1925 603762 Fax: +44 (0) 1925 603100 (Site) Email: david.meredith@stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk said:
For the GLUE2 XML rendering we have a design choice that I understand was also relevant in the design of the LDAP schema. Some feedback would be most helpful, especially as I understand that user requirements triggered similar changes in the LDAP schema (i.e. from style A to B as described below?)
To clarify what I think the issues are: o It's useful if a rendering technology can enforce restrictions in the schema, but not essential - in any case many things, e.g. the values of open enumerations, will have to be validated by some external tool. o In the LDAP rendering we have e.g. a GLUE2Endpoint objectclass with an attribute GLUE2EndpointServiceForeignKey to carry the relation to the Service. For a ComputingEndpoint we extend that with a GLUE2ComputingEndpoint objectclass with the additional specialised attributes. In the first version of the rendering that included a GLUE2ComputingEndpointComputingServiceForeignKey attribute for the redefined relation. However, that's somewhat clumsy because we then potentially have the relation published twice (or at least there are two different attributes that could carry it) - that wouldn't necessarily be untenable but it is likely to be error-prone and confusing, and doesn't seem to add any practical value. Also the relation itself is mandatory, but if you make both attributes mandatory you force it to be published twice and if you don't you risk not having it published at all. It's also worth noting that in LDAP these are just names, so e.g. there would anyway be nothing to prevent an attribute called GLUE2ComputingEndpointComputingServiceForeignKey containing the ID of a non-computing Service, or indeed any other kind of object. And similarly there would be nothing to prevent a plain Endpoint pointing to a ComputingService, which is the fundamental schema restriction at issue here. o Having the relation defined in the base class, e.g. GLUE2Endpoint, facilitates queries of the kind "find all Endpoints with certain properties and navigate to the corresponding Service" without needing to know what kind of Endpoint you have, and would be future-compatible with any new specialised classes with currently unknown names. Having it in the derived class seems to add no value as far as queries go, and is likely to make them more complex and more error-prone since you have to add extra special cases for all the specialised classes. It also follows the general spirit of inheritance and polymorphism that programmers are likely to find natural. After considering those factors we decided to deprecate the specialised relations, e.g. GLUE2ComputingEndpointComputingServiceForeignKey, and only publish and use the ones in the base class. However at present the schema does still define the specialised relations as optional attributes, so if there is any code which publishes them it doesn't break anything. On the other hand the base relations, e.g. GLUE2EndpointServiceForeignKey, are mandatory in the schema so there is no possibility to omit the relation completely. Stephen -- Scanned by iCritical.
Hi Stephen, Thanks for the clarification, most useful. Unless I hear any strong objections, I'll use the more generic/inherited element names (EndpointID, ShareID, ManagerID etc) to model the associations in the entity classes (including in the sub-type specialisations), i.e. Option B - Don't redefine the associations. I agree that defining the associations twice (as you describe below) is also clumsy/error prone and so will be avoided. Cheers David
-----Original Message----- From: Burke, Stephen (STFC,RAL,PPD) Sent: 28 February 2013 14:33 To: Meredith, David (STFC,DL,SC); glue-wg@ogf.org Subject: RE: XSD design choice related to LDAP
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk said:
For the GLUE2 XML rendering we have a design choice that I understand was also relevant in the design of the LDAP schema. Some feedback would be most helpful, especially as I understand that user requirements triggered similar changes in the LDAP schema (i.e. from style A to B as described below?)
To clarify what I think the issues are:
o It's useful if a rendering technology can enforce restrictions in the schema, but not essential - in any case many things, e.g. the values of open enumerations, will have to be validated by some external tool.
o In the LDAP rendering we have e.g. a GLUE2Endpoint objectclass with an attribute GLUE2EndpointServiceForeignKey to carry the relation to the Service. For a ComputingEndpoint we extend that with a GLUE2ComputingEndpoint objectclass with the additional specialised attributes. In the first version of the rendering that included a GLUE2ComputingEndpointComputingServiceForeignKey attribute for the redefined relation. However, that's somewhat clumsy because we then potentially have the relation published twice (or at least there are two different attributes that could carry it) - that wouldn't necessarily be untenable but it is likely to be error-prone and confusing, and doesn't seem to add any practical value. Also the relation itself is mandatory, but if you make both attributes mandatory you force it to be published twice and if you don't you risk not having it published at all. It's also worth noting that in LDAP these are just names, so e.g. there would anyway be nothing to prevent an attribute called GLUE2ComputingEndpointComputingServiceForeignKey containing the ID of a non-computing Service, or indeed any other kind of object. And similarly there would be nothing to prevent a plain Endpoint pointing to a ComputingService, which is the fundamental schema restriction at issue here.
o Having the relation defined in the base class, e.g. GLUE2Endpoint, facilitates queries of the kind "find all Endpoints with certain properties and navigate to the corresponding Service" without needing to know what kind of Endpoint you have, and would be future-compatible with any new specialised classes with currently unknown names. Having it in the derived class seems to add no value as far as queries go, and is likely to make them more complex and more error-prone since you have to add extra special cases for all the specialised classes. It also follows the general spirit of inheritance and polymorphism that programmers are likely to find natural.
After considering those factors we decided to deprecate the specialised relations, e.g. GLUE2ComputingEndpointComputingServiceForeignKey, and only publish and use the ones in the base class. However at present the schema does still define the specialised relations as optional attributes, so if there is any code which publishes them it doesn't break anything. On the other hand the base relations, e.g. GLUE2EndpointServiceForeignKey, are mandatory in the schema so there is no possibility to omit the relation completely.
Stephen
-- Scanned by iCritical.
participants (2)
-
david.meredith＠stfc.ac.uk -
stephen.burke＠stfc.ac.uk