[oslc-core] Comments on OSLCCoreSpecDRAFT

[Dave]

Thanks for the feedback Steve. My responses are below...


On Thu, Mar 11, 2010 at 3:17 PM, Steve K Speicher <sspeiche at us.ibm.com> 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