Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

in response to #1 of summary - the outcome of a relationship with regard
to/regardless of intention might be a consideration if its an option.


>-- Original Message --
>Date: Fri, 11 Jul 2003 23:56:02 -0400
>Cc: www-ws-desc@w3.org
>To: Umit Yalcinalp <umit.yalcinalp@oracle.com>
>From: Bijan Parsia <bparsia@isr.umd.edu>
>Subject: Re: Can someone recap the differences between @serviceGroup vs.
>definitions-targetNamespace    ?
>
>
>
>On Friday, July 11, 2003, at 08:51 PM, Umit Yalcinalp wrote:
>
>> Bijan Parsia wrote:
>>> On Friday, July 11, 2003, at 02:35  PM, Jon Dart wrote:
>>>> Jonathan Marsh wrote:
>>>>> Instead of
>>>>> introducing the "resource" entity, we can introduce an entity
>>>>> representing the "group".  The relationship between endpoint(s) and
>
>>>>> the
>>>>> group is that of "member of", instead of the fuzzier "manipulates".
>>>> I think this is a helpful change. IMO "group" and "member of" are 
>>>> actually fuzzier terms, in that there could be various kinds of and

>>>> rationales for grouping (of which "manipulate a common resource" 
>>>> might be one).
>>>
>>> That's exactly why they aren't fuzzy :) They just say that "this a 
>>> group; these are its members", no more, no less. "Manipulate a common
>
>>> resource" seems to say something substantive, but we don't want it 
>>> to, hence "the manipulation is undefined, and the resource can be 
>>> anything, including a set of naturally disjoint things", etc.
>>>
>>> I agree, of course, that this is a helpful change :)
>>
>> I am not sure that this is a helpful change. I believe the group 
>> concept is fuzzy.
>
>I have to strongly disagree. It's not fuzzy. It's not vague. It's not 
>undefined. It's not oddly defined. It clearly states what the 
>relationship is without ANY "hints" which *suggest* but don't *state*.
>
>Done right, it provides a hook for out-of-wsdl band information about 
>the *point* of the group, the *purpose* of the group, the *reasons* for

>grouping them so, etc. Whether WSDL *needs* to provide such a hook is 
>an open question (I suspect not). But to *purport* to give a specific 
>grouping (i.e., the group of "same resource manipulaters") while 
>leaving the nature of the specification almost entirely open (with 
>language such as "'manipulate' is undefined", or even "resource", where

>the resource in question can be either a single printer or a set of 
>unrelated printers), seems, if not fuzzy, worrisomely misleading. If we

>*do* mean something specific by "manipulates", and have some idea of 
>what sorts of resources are so manipulated, then we should be explicit.
>
>In any case, there are many reasons to group interfaces besides that 
>they manipulate the same resource (assuming SOME constrainsts on 
>"manipulate" and "resource). Why are we privileging this one?
>
>> With any abstraction and fuzziness introduced, there is always 
>> something lost.
>
>Abstraction != fuzziness, and there may be things gained. I would 
>contend that "manipulates some resource" is no *less* abstract (given 
>the actual (lack of) definitions proposed) and, due to the fact that 
>the language has extra connoations, more fuzzy. Lets call a spade a 
>spade unless we're actually willing to commit to pitchforks.
>
>> There may be many different rationales for grouping.
>
>Agreed. This is key to me. If the choice is between only 1 grouping 
>permitted (with the rest of the metadata out of WSDL-band), only 1 
>grouping permitted (but with very vague "permissive" semantics), there 
>there's no real choice. But I would prefer nothing at all to either of 
>these. If WSDL is the right place, technically and politcially and 
>usabilitily, to put this information, then you should be able to define

>mulitple groups.
>
>> However, when you introduce grouping with serviceGroup and the only
>> relationship that is implied is "member of", then this begs the 
>> question
>
>(Please ignore this pickiness but I can't help it: This isn't, 
>technically, "begging the question".)
>
>> of why we introduce the grouping at all when one can not
>> not define multiple groupings of a services.
>
>If you look at my prior posting, you'll see me critiquing some of the 
>concrete proposals for realizing it precisely on the grounds that 
>single grouping is pointless, IMHO.
>
>It would be pointed if there were a *clear*, *SPECIFIC*, general, and 
>useful rationale for grouping that served a large community such that 
>it was worth cluttering WSDL with. I really can't believe that 
>"manipulating the same resource" is such a rationale. Particular when 
>almost any relationship can fit that.
>
>Note that this relationship is differen than the one suggested by WSDL 
>1.1 as the useful one. Since sets of manipulations can be completely 
>independent.
>
>>  Many relationships between services are needed, why is this named 
>> grouping? I would think then it would be more powerful to define them

>> then externally to the definition of the service itself, hence RDF.
>
>Which was, in my prior post, my prefered choice.
>
>> What we lose by dropping the targetResource is the concept of 
>> "manipulation" and hence the implied concept of the state accessed via
>
>> multiple services.
>
>So, the burden, as I see it, of the priviledging this grouping 
>advocates is to show why *this relationship* should be priviledged. And

>this hold even if we have *mulitple* groupings. Why build in *this* 
>relationship? (I can think of several other key ones off the top of my 
>head. "Having the same author/mantainer" being one.)
>
>> The whole point of putting the targetResource was to indicate just 
>> that. We have discussed for several weeks now as to whether 
>> targetResource is illdefined, etc. Well, I think this is worse.
>
>I'm perplexed. You think that group membership is *more* ill/undefined 
>than targetResource? I just don't see how that can be. I *can* see that

>you might think that if we're going to only have one grouping, then it 
>should have a specific (useful) semantics. But then we should have an 
>actual specific semantics, which has been deliberately, explicitly NOT 
>given *and* we should have a good solid reason for selecting *THAT 
>SEMANTICS* to be *the* first class (and only) grouping rationale.
>
>My counterproposal (if we're not going to drop it entirely) would be to

>allow multiple groupings, with a hook for extensible metadata about the

>semantics of that grouping. I might go for a wsdl blessed "starter set"

>of rationales, if such a set could be reasonably identified.
>
>> If we were to retain targetResource, it seems that at least one can 
>> only infer a specific relationship, the manipulation of a resource 
>> that is accessed by multiple services that declare it.
>
>Except that non-manipulation is a permitted sort of manipulation and 
>the type of resource is unconstrained (so could be a disjoint set of 
>whatevers with no shared state).
>
>> This would be very useful in discussing other fundemantal concepts 
>> such as identity and state.
>
>Not without nailing it down a bit further, I'd say.
>
>> The serviceGroup thingy can not be used to express multiple 
>> relationships,
>
>Sure it can, if we let it :)
>
>>  it is fuzzier
>
>I really want that to be shown, rather than asserted. serviceGroup is a

>set of services with any further information about *why* they are 
>grouped having to be provided by something else. It's *VERY* clear that

>that's what it is.
>
>targetResource seems to be depending on the suggestiveness of the 
>language to "imply" (in the "suggest" not in the "entail" sense) some 
>stuff that, for some reason, the group (as a whole) is rather unwilling

>to explicitly state. This is clear? I think not *because* it's 
>unsettled whether this language actually fixes the relationship.
>
>>  and can not be used as a building block.
>
>Well, it depends what you're building. It seems perfectly reasonable as

>a place to hang further information.
>
>>  IMHO,  targetResource is better defined in comparison.
>
>I really think you're conflating "better defined" with "more useful 
>concept". Or even "more specific concept".
>
>In any case, I think it manifestly clear that the current spec does 
>*not* well define it, as it doesn't define it at all 
>(http://www.w3.org/TR/wsdl12/#intro_ws):
>
>"""Figure 1-2 shows two services (Service1 and Service2) bound to the
>same resource (Resource1), but offering different interfaces (Interface1
>and Interface2). Interface1 and Interface2 may be related to each other,
>but this specification is NOT defining what this relationship might be.
>For example, Interface1 may be an operational interface, may Interface2
>might be a management interface."""
>
>Oh, and it gets worse 
>(http://www.w3.org/TR/wsdl12/#Service_resource_attribute):
>
>"""2.13.2.2 targetResource attribute information item with service 
>[owner]
>
>The targetResource attribute information item identifies the resource 
>that the
>service is a representation of."""
>
>Am I looking at the wrong version of the WD? Or is there another 
>definition somewhere, contrary to the claims of the introduction?
>
>---Summary
>
>1) "targetResource", et al, is at best suggestive of some relationship,

>and that suggestion is not uniform across members of the WG. It 
>explicitly is left undefined with the possible relationships (as 
>mentioned in the text) ranging from "representing", to "operating", to 
>"managing". I contend that it's not well or clearly defined in the 
>spec, and it's very unclear to me, personally, what relationships are 
>intended.
>
>2) serviceGroup defines a set membership relationship only and leaves 
>the rationale for that grouping for out-of-wsld-spec-band 
>determination, say, by some RDF. It is not illdefined or undefined and 
>it clearly communicates that if you want a group with some particular 
>semantics you should check the out of band info. It also provides a 
>hook by providing a uri that can be the subject of RDF assertions 
>detailing the purpose of the grouping and what further information can 
>be infered from that grouping
>
>3) Having only one serviceGroup is wrongheaded. If having more than one

>is cumbersome, then that suggests we should leave grouping to things 
>other than WSDL.
>
>4) If there is a grouping/grouping purpose that is either supremely 
>common, highly related to other bits of WSDL, etc. then that *may* be 
>an argument for privileging it. But I would hold that a) the barrier to

>such an asymmetric treatment should be high and b) that the semantics 
>of the distinguished rationale should be well defined in the spec. See 
>1 for why targetResource currently fails.
>
>Cheers,
>Bijan Parsia.
>

Received on Saturday, 12 July 2003 05:23:01 UTC