Hi Stephen, On Thursday 10 April 2008 00:32:47 Burke, S (Stephen) wrote:
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!")
I think this illustrates our different points of view. If I may summarise your position (please correct me if I'm wrong), you see object classes as necessarily being something concrete---something you can (in principle) hold in your hand (e.g. a cup), or that you could separate and similarly hold in your hand. From your point-of-view, a smile cannot be held in a hand, so necessarily cannot be an object. If so, I see I have a different point-of-view. For me, an object class is any well-defined logical concept defined only by its relationships with other object classes and the attributes it may have (there are probably some stronger statements one can make). An object class may (or might not) have an independent life from other logically defined concepts. For example, a smile, whilst having no independent life from the mouth it describes, is still a pretty well defined concept in most peoples heads. For example: http://images.google.co.uk/images?um=1&hl=en&q=smile&btnG=Search+Images or, perhaps better results with ESP: http://www.captcha.net/esp-search.html In a "hand wavy" way, the fact that Google or ESP can find a bunch of images that people can identify something that's the same ("yep, they're all smiling") suggests that there is some common concept that they all have. There are then two questions: a. do we want to model this common feature? b. how do we best model this feature? If the answer to a. is "yes", then the question is how best to model it. If there is no metadata associated with the concept (someone is either smiling or they're not), then it could be as an attribute or an attribute value in an enumeration. For example: Face: smiling <boolean> := true {or false} or Face: mouth-posture <open enumeration> := smiling {or shocked, upset, ...} If there is metadata to be recorded and we want to keep this as an attribute, then this metadata must either be encoded within the attribute value (embedding the metadata within the name) or be encoded as associated attributes; either: Face: mouth-posture <open enumeration> := smiling-smirk, smiling-broad, smiling-faint, ... or Face: mouth-posture <open enumeration> := smiling smiling-type <open enumeration> := smirk {or broad, faint, ...} respectively. (There may be other ways of recording the information as attributes, but I can't think of them just now.) Neither of these solutions is very satisfactory, as it requires the client to understand the additional semantics; e.g., if you see "smiling-", split at the "-" and treat the second part as a type value; or, if you see "smiling" look for the smiling-type attribute, ignore it otherwise. I would say that the natural solution is to express the information as a new object class, subclassing from a generic type, with the attributes you need to record. Face: mouth-posture <mouthPostureType> := smileMouth smileMouth extends mouthPostureType: smiling-type <open enumeration> := smirk {or broad, faint, ...} The same information is recorded, but here the structure is made explicit. One of the goals of modelling is to make community knowledge explicit, so writing clients that consume this information is easy. This is how I see the transition from Glue-1.3 to Glue-2.0: GLUE-2.0 should (if feasible) make explicit what was previously implicit knowledge (such as, custodial-online, means D1T1, means guaranteed to be stored on disk and tape).
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
OK, counter example. When you buy the mug at the shop, they give you a till receipt (typically). That receipt proves that you've bought the mug in the store. If you are challenged whilst leaving the shop, you can produce the receipt, proving you've bought that mug. So the receipt is a concrete object that represents your ownership of that mug. Your ownership is transferable (you give the receipt and mug to someone else whilst in the shop, they walk out with the mug) and sharable (a group of people all club together to pay for the mug, they sign a document saying they have part-share of the ownership, the two documents are stabled together).
if I own two mugs and give one away it doesn't affect the other one
True, no one suggests that it is should affect the other.
(rules and capacities may be equal but that doesn't make them identical).
True, again no one is suggesting that two objects with equal properties are the same thing.
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.
(I fear you're grasping at straws here ;-) Network infrastructure (networks, routers, firewalls, etc...) connects everything together, this isn't special about CEs and SEs that they require network connectivity.
It might well be pointless to publish [network/firewall/policies] without relating it to a CE and an SE, but not nonsensical (indeed in principle it's interesting to know it for a UI).
Yes, indeed. In effect the CE-SE bind is some summary information, giving a brief describion of the "connectivity" between a CE and an SE. It summaries the network topology, configuration and policies that would be (potentially) too complex to represent explicitly. But, going back to your original point: I can't hold a CE-SE bind in my hand, but I can hold a network cable in my hand, likewise a switch, router (if not too heavy). If I followed your argument to its logical conclusion (and if I understand it correctly), I should replace CE-SE bind objects with a description of the networking (routers, switches, cabling) and allow jobs to deduce which SE they should use.
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.
OK, I accept the analogy: comparing an AccessProtocol to a handle of a mug (more or less) works, although there's a few questions about the similarity of snapping off the handle vs. "detaching" an AccessProtocol. But, this then leads to the question: what is it about the handle of a mug that means you're happy describing it with an object? Sorry for the noise, but I don't understand! Cheers, Paul.