Paul Millar [mailto:paul.millar@desy.de] said:
As a counter-example, the same is true for the CE-SE-Bind (in whatever form it might take). This leads no independent existence from the CE and SE it connects, yet is represented as an object.
I'll reply to the rest tomorrow, but just on this since I thought of another example: consider a coffee mug. That has a handle, and in principle I could consider it as a separate object (I could break it off), although for any practical purpose it's only useful when attached to the mug. Now consider that the mug has a capacity (I can put 300 ml of coffee in it). In that case it clearly makes no sense to consider the capacity as having an independent existence of any kind, there's no way to detach it from the mug. ("I've often seen a cat without a grin," thought Alice; "but a grin without a cat! It's the most curious thing I ever saw in all my life!") Similarly with the MappingPolicy: if the mug belongs to me that's an access rule, and although other things may belong to me the specific "instance" of belonging that applies to the mug is not transferrable or shareable - if I own two mugs and give one away it doesn't affect the other one (rules and capacities may be equal but that doesn't make them identical). In the case of the CESEBind there is something real underneath, some kind of network connection and/or firewall rules and/or policies about which protocols are allowed where. It might well be pointless to publish such information without relating it to a CE and an SE, but not nonsensical (indeed in principle it's interesting to know it for a UI). For that matter you could say the same about e.g. the AccessProtocol: we wouldn't publish one independently of an SE, and indeed we can't because it only has a LocalID. Nevertheless it does deserve to be an object and not just an attribute of something else because it describes a discrete part of the SE, much like the handle of a mug. Stephen