Thanks for the feedback Steve. My responses are below...
On Thu, Mar 11, 2010 at 3:17 PM, Steve K Speicher <[email protected]> wrote: > These comments are on this document > http://open-services.net/bin/view/Main/OSLCCoreSpecDRAFT > > 1) In "Design Considerations", I might add a few other points: > - "simplest things that work" for key integration scenarios > - "loosely coupled" - perhaps this is implied by "Build on the WWW", > though a key point is to allow versions and implementations to evolve, while > things "still work" I added those two suggestions to the issue tracking page with name "SteveSpeicher via DaveJohnson" > 2) In "Glossary of terms" you reference the home page of w3.org, wouldn't it > be more appropriate and helpful to reference directly the document that > defines these terms? The "(reference: HTTP)" part indicates that you look to "HTTP" in the reference section. I link to RFC-2616 there. > 3) In "Glossary of terms" there is a reference to "Application Lifecycle > Management (ALM) product ", since we have a PLM-ALM topic, should we expand > this to be something more open. A nit. Good one. It's on the issues page now. > 4) For "OSLC Query Resource" you mention "list of links", I assume this > means "list of URIs"? Perhaps it should say this as links isn't in the > glossary. Added this one too. > 5) For "URI Query Parameters", this should also include "oslc.prefix" to > allow for defining namespace prefixes Added. > 6) Terminology inconsistency, in "Resource Creation" you refer to "Creation > Resource" instead of "OSLC Creation Resource". This occurs in a few other > places. Added. > 7) In section "Unknown properties and content", it is unclear why a client > MUST preserve all unknown content? What does preserve mean here? > I think this is saying that OSLC Services are allowed to extend the resource > definitions, providing properties from other namespaces, which the clients > much not lose in transmission (updates) Yes, this is a burden that we place on clients to enable service providers to add properties and other things to resources that are not in the OSLC specifications. Preserve means that, when a client updates a resource, it should not change or delete things that it does not understand. > 8) In "OSLC Properties", I'm not sure I understand the need for "oslc:etag": > is there some use cases that could be provided why this OSLC Property is > needed? I have the use cases for the others already known but they are not > explicitly stated. I added it there because I saw it in one of the OSLC specs under development and wanted to get it on the table. It's useful as an alternative to dc:modified for caching purposes. > 9) In "Service Resources", it would be good to have some additional > information: > - how service discovery works > - nested service resources Yes, I think we will need much more than the four URI valued properties that I put in the draft. > -) lack of usage of HTTP status codes: success or error code handling: when > 400 vs 404 vs 409 (see CM spec)? > -) lack of error message > -) caching and eTag handling Added these too. Thanks, - Dave
