RE: Separate concepts for "service" and "targetResource?" (was RE : /service/@targetResource ?)

> The other is single-reference. In this case there is exactly one 
> collection of services and the easiest way to express that is by having 
> them all associated with some common name, whether it's the 
> targetResource or even just the targetNamespace. I think the 
> concept you need here is service provider. 

I can understand that. But a "service provider" is different than the concept of "resource" as intuitively understood. 

To give an example, a service provider might make available as services a mortgage processor, a car loan processor, a personal loan processor, and a management module to manage all of them. Each of these services has its own "resource" (the specific loan processor, in the loan cases, or the management module).

Now, if I wanted to specify the relationship between the management service and one of the loan services via one shared URI, the "service provider" URI would do, but not the "resource" URIs (which are different between the two services).

As I said before, it seems to me that the "resource" concepts only helps in some particular cases. The "service provider" concept helps in other cases. In yet other cases a different concept might be needed to express services aggregation. My question is: do we have to go through the trouble of identifying all these concepts, clarify their meaning, assign them URIs, etc, just for the purpose of expressing aggregations that in many cases are just application-specific?

Ugo

Received on Thursday, 22 May 2003 11:04:32 UTC