W3C home > Mailing lists > Public > public-ws-resource-access-notifications@w3.org > October 2009

[Bug 8124] New: policy URIs - what do they reference?

From: <bugzilla@wiggum.w3.org>
Date: Thu, 29 Oct 2009 15:32:39 +0000
To: public-ws-resource-access-notifications@w3.org
Message-ID: <bug-8124-2780@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8124

           Summary: policy URIs - what do they reference?
           Product: WS-Resource Access
           Version: FPWD
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: All
        AssignedTo: public-ws-resource-access-notifications@w3.org
        ReportedBy: dug@us.ibm.com
         QAContact: public-ws-resource-access-notifications@w3.org


For each spec (except MEX) we've defined policy URIs -for example,
in WS-Transfer we now have the XML prefix "wstrp" mapping to:
   http://www.w3.org/2009/09/ws-trp

The WG needs to decide a couple of things:
1 - do we want to have a separate NS for the policy assertions or should
    we just reuse the normal NS for each spec
2 - if we do have separate namespaces then what do those URIs point to?
    For example, does http://.../2009/09/ws-trp reference the Transfer spec?
    What do we put in the Namespace table? Right now for "wstrp" it says
    "This specification".  Which, if remains, why do we have a separate NS?

If we see the policy assertions having a separate lifecycle from the specs
then a separate NS makes sense.  But if they will pretty much always be
tied to the spec then a separate NS seems pointless.

No proposal at this time - but we should discuss.


-- 
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 Thursday, 29 October 2009 15:32:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 October 2009 15:32:42 GMT