[Bug 7791] New: Consistent Policy applied to a set of resources

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7791

           Summary: Consistent Policy applied to a set of resources
           Product: WS-Resource Access
           Version: FPWD
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transfer
        AssignedTo: public-ws-resource-access-notifications@w3.org
        ReportedBy: paul@wso2.com
         QAContact: public-ws-resource-access-notifications@w3.org


In the current specifications, the only way of looking up the policy of a
resource is to do it at 'runtime' via MEX. An example: I create a resource
using the resource factory. But until I have a resource there is no policy for
that resource. Now, the 80/20 (or maybe even 95/5) case is that ALL the
resources that are created by a singled ResourceFactory will have a consistent
policy. In that case, it would be *very* valuable to be able to find out this
policy ahead of time (design time). Take a simple example: I might be writing a
client to a printer. The resource factory allows me to create print jobs and
then deal with those. I don't want to have to create a print job just to
understand the policy associated with that print job. 

There isn't a fully fledged proposal at this point, but the main thrust of this
is to add a policy parameter to the ResourceFactory policy. This parameter is
optional. If it doesn't exist then you still have to go to an individual
resource to find its policy. But if the parameter <ResourcePolicy> exists, then
this is a guarantee from the ResourceFactory that all resources created MUST
have that policy. The contents of the parameter are a valid WS-Policy
applicable to a resource endpoint.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.

Received on Friday, 2 October 2009 08:44:06 UTC