+1 on the revised wording.

Regards,
Mike

Michael Fiedler
IBM Rational Software
[email protected]
919-254-4170


                                                                       
             Martin P Pain                                             
             <[email protected]                                         
             m.com>                                                     To
                                       Michael F Fiedler/Durham/IBM@IBMUS,
             04/16/2013 04:52                                           cc
             AM                        [email protected],    
                                       "Oslc-Core"                     
                                       <[email protected]
                                       t>                              
                                                                   Subject
                                       Re: [oslc-core] Issue 42 proposed
                                       resolution - UPDATED with language
                                       to remove error and add warning 
                                       header                          
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




The text "The provider SHOULD NOT return an error (HTTP error status code
or OSLC error resource) when unsupported search properties are present" is
a little ambiguous - "The provider SHOULD NOT return an error (HTTP error
status code or OSLC error resource) as a result of unsupported search
properties being present" would be less so.

Martin




From:        Michael F Fiedler <[email protected]>
To:        [email protected],
Date:        15/04/2013 18:15
Subject:        [oslc-core] Issue 42 proposed resolution - UPDATED with
language to remove error and add warning header
Sent by:        "Oslc-Core" <[email protected]>



Revised proposed resolution for issue 42 which incorporates feedback from
last week's Core workgroup meeting.   I am re-copying the issue summary
here - proposed resolution wording follows.   The final two sentences are
the changed content.

======  SUMMARY ========
Core issue #42 [1] deals with service provider behavior when a consumer
requests selective properties or attempts to filter/search using properties
not known to the provider.   The e-mail thread describes three variations
on the issue:

1. Client requests selective properties (oslc.select/oslc.properties)
defined as optional in the spec and which are not supported by the provider
[1]
2. Client requests selective properties not defined in the specification
[1]
3. Client tries to filter or search (oslc.where) using a property not
supported by the provider [2]

The issue was discussed on-list, in early 2012 workgroup meetings and it
appears some side meetings were held as well to investigate the behavior of
existing implementations.   Based on the discussions, the following
informative text is proposed for the Core specification.   The workgroup
should discuss the content and whether it goes in V2 or is deferred to V3.

====== PROPOSED RESOLUTION =======
To be inserted as a new sub-heading under "Unknown Properties and
Content" [3]

(This section is informative.)

A consumer can send an OSLC query with a request for selective properties
(oslc.properties, oslc.select) which the provider does not recognize.
These properties could be unsupported properties from an OSLC specification
or properties not included in an OSLC specification.  When unsupported
selective properties are present in an OSLC query, the provider is
encouraged to ignore these properties and form the query response as if
they were not present.  Other recognized selective properties on the query
should be honored.

A consumer can send an OSLC query with a a request to search on specific
properties (oslc.where) which the provider does not recognize.  These
properties could be unsupported properties from an OSLC specification or
properties not included in an OSLC specification.  When unsupported search
properties are present, the provider is encouraged to follow the semantics
of SPARQL WHERE as it relates to OSLC query (see:
http://open-services.net/bin/view/Main/OslcSimpleQuerySparqlV1#Example_2_Searching_for_Resource
).  If the property is not present in the RDF graph of resources queried,
no resources will match the query.   The provider SHOULD NOT return an
error (HTTP error status code or OSLC error resource) when unsupported
search properties are present.   The provider MAY include a standard HTTP
Warning header in the response to indicate that a search property is not
known or not supported.


[1] -
http://open-services.net/pipermail/oslc-core_open-services.net/2012-March/001257.html

[2] -
http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001287.html

[3] -
http://open-services.net/bin/view/Main/OslcCoreSpecification#Unknown_properties_and_content




Regards,
Mike

Michael Fiedler
IBM Rational Software
[email protected]
919-254-4170_______________________________________________
Oslc-Core mailing list
[email protected]
http://open-services.net/mailman/listinfo/oslc-core_open-services.net


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Reply via email to