RE: [Bug 8290] New: "Requirements" section confusing and unnecessary

The Requirements section is useful in that it provides the design requirements the specification aims to meet. I suggest making this section clearer (by modifying the ambiguous statements) instead of dropping it.

-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org [mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf Of bugzilla@wiggum.w3.org
Sent: Friday, November 13, 2009 3:30 PM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 8290] New: "Requirements" section confusing and unnecessary

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

           Summary: "Requirements" section confusing and unnecessary
           Product: WS-Resource Access
           Version: PR
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: MetadataExchange
        AssignedTo: public-ws-resource-access-notifications@w3.org
        ReportedBy: gilbert.pilz@oracle.com
         QAContact: public-ws-resource-access-notifications@w3.org


Section 2.1 "Requirements" attempts to outline the requirements behind WS-MEX, presumably to aid in a better understanding of the spec. Unfortunately this section fails to accomplish that goal. The relationship between the requirements and the spec-defined entities (XML elements, SOAP messages) is unclear. For example, "Support future versions of known metadata formats". How is this requirement satisfied? Other requirements are vague ("Leverage other Web service specifications . . .") or make use of ill-defined terms (". . .
metadata-driven message exchange").

We could attempt to re-write this section to correct these flaws but, since this section really isn't necessary, that seems like more effort than it is worth.

Proposal: remove Section 2.1.


--
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 Saturday, 2 January 2010 18:50:11 UTC