[glue-wg] Notes: GLUE WG session at OGF 40

[Florido Paganelli]

Hi all, sorry for being not present all this time but my time for GLUE2
is getting smaller and smaller.

On 2014-01-21 18:38, stephen.burke at stfc.ac.uk wrote:
> Paul Millar [mailto:paul.millar at desy.de] said:
>>  From the spec. it is legal to publish Entity (at least, nothing says
>> you can't) and many of the top-level classes (Service, Share, etc).
>> Publishing Domain is expressly forbidden, however.

Paul is right, I think this should be fixed in the schema. Domain should
be abstract. I missed that. Was there a reason to make it STRUCTURAL? I
kept it like that during my revision but it might be changed into ABSTRACT.

> 
> I'm not sure why you think that - many of the class definitions forbid it, e.g. "The Share class is an abstract entity that MUST NOT be instantiated". In fact in LDAP most of them are concrete and you could create prototypes, but not Entity itself so you can't have generic objects. In theory I guess we could define a generic prototype object with an attribute to carry a new type name. However, while that would let you prototype attributes for a new class type I don't think there's any way in the abstract model to prototype relations - a relation is bidirectional so it intrinsically changes the related class definition too. In LDAP you could do it to some extent because relations are just represented by attributes, but it might well be rather clumsy and wouldn't in general be translatable to another rendering technology. You would also reopen the can of worms about the DIT ...
> 
>> So, we might want to revisit making Entity ABSTRACT in the LDAP schema.
> 
> It pretty much isn't possible, for example we put the ID attribute in the derived objects rather than Entity itself.

I agree with Stephen, and moreover I don't see the benefit of it... in
the end isn't it Service the main entity we always want to model?

On Extensions: these are a bad way of extending. We had the same problem
while designing EMI-ES. The reason is they increase complexity on the
client side, that needs to retrieve those localIDs.

A nice way of extending the schema (at least for XML) would be better,
and I think we achieved that with the XML rendering doc.

For LDAP, it doesn't really matter, due to the nature of LDAP objects
that can be composed out of other objects.

In my opinion, the Extension method described in GFD.147 it's
theoretically nice (can be applied regardless of the technology) but
practically cumbersome (every technology has his own good way of
extending a schema, and Extensions add unnecessary/unwanted complexity
in both LDAP and XML).

-- 
==================================================
 Florido Paganelli
   ARC Middleware Developer - NorduGrid Collaboration
   System Administrator
 Lund University
 Department of Physics
 Division of Particle Physics
 BOX118
 221 00 Lund
 Office Location: Fysikum, Hus B, Rum B313
 Office Tel: 046-2220272
 Email: florido.paganelli at REMOVE_THIShep.lu.se
 Homepage: http://www.hep.lu.se/staff/paganelli
==================================================