RE: targetResource wording

To be honest with you, this targetResource thing reminds me of SOAPAction in SOAP 1.1. Nobody knew what exactly it meant, different implementations assigned all sorts of different semantics to it, and the result was an endless stream of interoperability issues.
 
Ugo

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Sunday, June 22, 2003 7:59 AM
To: Ugo Corda; dbooth@w3.org; www-ws-desc@w3.org
Subject: Re: targetResource wording


Exactly.
 
If I have a printing service that assigns jobs to multiple printers, then I would need some way to specify all the printers associated with the service. I certainly don't want to create a different service for each printer -- the whole point of the service is to assign the printing jobs based on some set of parameters (speed, quality, location, etc). So in this situation, I'd like the ability to associate multiple target resources with one service.
 
This whole concept of one interface per service and one target resource per service solves a set of problems for one set of use cases, but it imposes a host of new problems for a different set of use cases. 
 
I'd really like to see us renew the debate on one interface per service. Obviously we have not achieved consensus on this issue.
 
Anne

----- Original Message ----- 
From: Ugo  <mailto:UCorda@SeeBeyond.com> Corda 
To: dbooth@w3.org ; www-ws-desc@w3.org 
Sent: Saturday, June 21, 2003 8:30 PM
Subject: RE: targetResource wording


David, 

>The targetResource is intended to help in discovery or selection of an appropriate service. 

My question then would be: why allow only one targetResource? 

In your printer example targetResource=" http://example.com/printers/HPLaserJet3200/SN1235654007" is used to establish a relationship between PrinterService428 and ManagementService3456 (the relationship being that both services operate on the same physical printer).

But I might also want to express other relationships of PrinterService428 with other services. For example, I might want to say that PrinterService428 relates to PrinterService500 because of the fact that the associated physical printers are both located on the first floor. I'll use targetResource=" http://example.com/printers/firstFloorBuildingA" to express this relationship. (This "resource" corresponds to a more abstract concept than targetResource=" http://example.com/printers/HPLaserJet3200/SN1235654007", but that should not be a problem because, as you said in a previous note, "a resource can be anything -- a physical object, an abstract concept -- anything").

The same way you use the first targetResource to find a management service for PrinterService428, I could use the second targetResource to find all the printers located on my floor (because I don't want to go up and down the stairs all the time). So I use targetResource=" http://example.com/printers/firstFloorBuildingA" and I get back two printer services: PrinterService428 and PrinterService500.

But now I need two targetResource's to be associated with PrinterService428. And, of course, I could go on with other types of relationships, e.g. all the black&white print services in the building, etc.

So, why just one targetResource? 

Ugo