[glue-wg] XSD design choice related to LDAP

[david.meredith at stfc.ac.uk]

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 at ogf.org
> Subject: RE: XSD design choice related to LDAP
> 
> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
> david.meredith at 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.