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.