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

On Monday, July 14, 2003, at 05:36  PM, Jeff Mischkinsky wrote:
[snip]
> It was not to introduce a general grouping relationship.

Without more definition (e.g., ANY definition) it certainly doesn't do 
*more* than introduce a general grouping relationship. And it might not 
introduce the relationship desired, given certain definitions.

(I, for one, advocated considering serviceGroup precisely because, 
afaict, no one wants to specify the semantics of targetResource 
*beyond* "these interfaces relate somehow left to applications or other 
specs to determine". If that's it, then lets call it what it is.)

> The question that targetResource was intended to *help* answer was 
> typified by the example of having a printer PRINT interface and a 
> printer PRINTADM interface. The question was how can i tell when an 
> instance of the PRINT interface and an instance of the PRINTADM 
> interface are operating on the "same" printer.

Suppose the PRINTADM has two operations, getPrinterInfo and 
notifyPrinterRepairPersonOfProblem. The latter sends email to a person. 
What resource does PRITNADM manipulate? Is it the same as the PRINT 
interface? Is it a printer?

Is this sort of grouping uncommon? Unlikely?

Perhaps a more compelling example. We have PRINTADMforPrinterFoo, and 
PRINTADMgeneric. Each contains one operation getPrinterInfo, but in the 
latter its parameterized to any of a dozen printers, depending on which 
id you pass it, but including printer Foo, Do these interfaces have the 
same targetResource? What is it? What exactly can we infer about them 
sharing (or not sharing) a targetResource absent other information?

[snip]
> The issue I have with changing the notion to group membership is that 
> there is no definition, even a loosey/goosey one, of what said 
> membership means.

It explicitly is silent on the *further significance* of the 
membership, but WSDL 1.2, as it stands, is silent about the 
significance of the relationship indicated by targetResource. I'd 
rather have something I can hang more specific information on, than try 
to rely on something that has some intuited meaning to some folks, but 
not to others.

>  Take my example above of PRINT and PRINTADM. I don't think I can 
> infer anything useful about the fact that 2 instances have the same 
> group id. It might mean they manipulate the same printer, but it might 
> just as well mean that they manipulate printers made by the same 
> manufacturer, possibly the same printer model, or maybe the printers 
> they manipulate are owned by the same company, or are located in the 
> same building.

Fairly reasonable set of groups with varying purposes. At the moment, 
on can bend targetResource, afaict, to cover all of these. The 
relationship is undefined!

> Personally, I thought the notion that we have of targetResouce served 
> a useful purpose in many, many cases. I can't see any real world 
> useful purpose in this notion of service group. as currently defined.

Hmm. It's a hint that someone, probably the service authors, thought 
they bore some interesting relationship, and you may want to find out 
more about it? What more does targetResource give you, currently? Even 
with the "manipulates" definition (note that "manipulates" isn't in the 
current WD)?

> So i'm afraid i'd vote to either keep targetResource as is (modulo 
> some wordsmithing which I don't think is needed since manipulate is 
> adequately enough defined to be useful) or to remove serviceGroup.

It seems especially fraught when the implied type of the target can 
shift dramatically given reasonable changes to the interface.

serviceGroup also more precisely replicates, afaict, the WSDL 1.1 
semantics, such as they aren't :)

OTOH, skiming WSDL files on XMethods....most are pretty focused. Of 
course, many are one operation deals, as well :) So I don't really have 
any empirical evidence, either way, actually.

Cheers,
Bijan Parsia.

Received on Monday, 14 July 2003 22:43:57 UTC