Re: targetResource wording

RE: targetResource wordingSorry, I've had a copy and paste mistake,
I wanted to say
<service Print targetResource="printers">  
        <print>
    </service>

    <service PrintManage  targetResource="printers">  
        <manage>
    </service>
Thanks
  ----- Original Message ----- 
  From: Sergey Beryozkin 
  To: Anne Thomas Manes ; Ugo Corda ; dbooth@w3.org ; www-ws-desc@w3.org 
  Sent: Monday, June 23, 2003 10:38 AM
  Subject: Re: targetResource wording


  Hello,

  I may be wrong but it seems now to me that the issues of having a single interface per service and of using @targetResource for the purposes of selecting between multiple pairs of printers and printerManagers (or other related services) are somewhat orthogonal to each other.
  It looks like @targetResource has two roles :
  the first one is to express this :
      <service PrinterAll> 
          <print>
          <manage>
      </service>

       with this :
    
      <service Print targetResource="printers">  
          <print>
          <manage>
      </service>

      <service PrintManage  targetResource="printers">  
          <print>
          <manage>
      </service>

        At this stage there's still an issue of how to print on and manage multiple printers, irrespectively of whether we have a single interface or not. So @targetResource offers one optional way to do it, that is to allocate a service per every resource, and have the same (or perhaps less ) number of services managing those resources, and by this it solves a set of problems for one set of use cases, as you said. 
  This approach, IMHO, may not be ideal when resources are selected by some set of (changing) preferences, where there may be maintenance/synchronization issues related to updating potentially a big directory of service descriptions, or when one just doesn't like creating a service description per every resource, etc. But if I don't want to use @targetResource, then I'm free not to, I'd look for applying what is coming from WSDL R085 requirement, or I would think of passing a printer name/etc with every request as part of its metadata, etc.
  Cheers
  Sergey Beryozkin


    ----- Original Message ----- 
    From: Anne Thomas Manes 
    To: Ugo Corda ; dbooth@w3.org ; www-ws-desc@w3.org 
    Sent: Sunday, June 22, 2003 3:59 PM
    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 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