Re: Proposed text for clarifying protocol conformance

Looks OK to me.

(are we going to "at risk" this to allow for push back on the need for 
all 3+2 forms of operations?  Done this way, "at risk" is at most 
removing features and so would not force an LC cycle).

 Andy

On 03/01/12 15:55, Lee Feigenbaum wrote:
> In http://www.w3.org/2009/sparql/docs/protocol-1.1/Overview.xml#conformance
>
> """
> A conformant SPARQL Protocol service:
>
> 1. must implement either the query operation or the update operation in
> the way described in this document ("SPARQL 1.1 Protocol");
>
> 2. may implement both the query and update operations;
>
> 3. must implement all three forms of the query operation (query via GET,
> query via POST with URL-encoded parameters, and query via POST directly)
> if it implements the query operation
>
> 4. must implement both forms of the update operation (update via POST
> with URL-encoded parameters and update via POST directly) if it
> implements the update operation
>
> 5. must be consistent with the normative constraints on SPARQL Protocol
> services (indicated by [RFC2119] keywords) described in 4. Policy
> Considerations.
>
> A conformant SPARQL Protocol client:
>
> 1. must generate requests for either the query operation or the update
> operation;
>
> 2. may generate requests for both the query and update operations;
>
> 3. may generate requests for any or all of the three forms of the query
> operations if it generates query requests;
>
> 4. may generate requests for either or both of the two forms of the
> update operations if it generates update requests;
>
> 5. must be consistent with the normative constraints on SPARQL Protocol
> clients (indicated by [RFC2119] keywords) described in 4. Policy
> Considerations.
> """
>
> Any suggested changes or support for this?
>
> Lee
>

Received on Wednesday, 4 January 2012 21:56:55 UTC