> > |
- Define how service features can be invoked
- Define error reporting and handling
The Payload:
- In the case of ADQL is the responsibility of the VOQL-WG
- In the case of Simple Access is the subject of a separate but related standard defined by DAL-WG
Defining the Standard
These then are the steps and documents I would like to see leading to the drafting of the standards:
- Document the Use Cases describing the system in question (e.g. IVOA Table Access) on the IVOA Wiki
- Describe the software architecture (this is likely to be common across many such systems)
- Define the Service Interfaces that will be required
- Define the Protocols those Interfaces will support
- Define the Payload the Service will process (this include inbound and outbound and may be defined by an IVOA WG other than DAL)
- Discuss and draft the Standard(s) (both Protocol and Payload) required
- Where the Protocol and the Payload are tightly bound for reasons of convenience, note this and draft accordingly
Once agreed and drafted, Standard(s) will be prosed as a Recommendation(s) following the usual IVOA mechanisms.
Definitions
- Client: "A computer application, such as a web browser, that runs on a user's local computer or workstation and connects to a server as necessary."
- Server: "A software system designed to support interoperable Machine to Machine interaction over a network.
- Protocol: "A convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints"
- Payload: "The data, such as a data field, block, or stream, being processed or transported; the part that represents user information and user overhead information. Note that the payload does not include system overhead information for the processing or transportation system."
- Contract: "...how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits"
- System: "a set of computer equipment and programs used together for a particular purpose"
- Use Case: A use case bridges the gap between user needs and system functionality by directly stating the user intention and system response for each step in a particular interaction. Each use case should show a straightforward example of the user succeeding at a goal. The steps in a use case are almost always a linear sequence.
- Use Case Suite: An organized suite of use cases is needed to fully specify the software requirements. A Use Case Suite is effectively table of contents for the individual use cases.
References
-- KeithNoddle - 20 Sep 2007 |