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@stfc.ac.uk wrote:
Paul Millar [mailto:paul.millar@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@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================