[oslc-core] Comments on OSLCCorePartialUpdateDRAFT

[Dave]

Thanks again for the detailed comments Steve.

Responses inline below...

On Mon, Mar 15, 2010 at 9:07 AM, Steve K Speicher <sspeiche at us.ibm.com> wrote:
> These comments are on:
> http://open-services.net/bin/view/Main/OSLCCorePartialUpdateDRAFT
>
> 1) This appears to address two separate issues:
> a) updating only a subset of the properties of a resource
> b) ability to add/update/remove values for a multi-valued property
> Perhaps it would be more clear if this distinction was made

Yes, I agree a better summary at the start would be helpful.

The partial update scheme that I present is pretty limited. I don't
want to invent the universal partial update scheme for all use cases.
What is here are some ways to do partial update on properties of a
resource and the idea, in my mind, is to allow OSLC service specs to
pick the couple of these techniques that they want to support
depending on the nature of their resources.

It does not support modifying specific nested properties, but since
OSLC resources are relatively flat (and we want them to remain so)
this is not a big limitation.


> 2) This statement is not completely accurate:
>>>The Partial Update pattern used in the OSLC Change Management 1.0
>>> specification has a couple of short-comings:
>>>   - Does not work well for multi-valued properties.
> It does work well, it just doesn't fit into some RESTful principles or RDF
> necessarily cleanly.  Implementations have used this successfully.  Perhaps
> it should be made clear what the design flaw is.

I'm not sure I want to compare with other techniques at all here in
the spec, but you are right that if I do I should be specific about
the short-comings I mention.

What I was referring to was the fact that to update a single value of
a multi-valued property, you have to update them all.


>>>   - Assigns a URI to a property, effectively making the property into a
>>> resource. "
> Yes, there is an added an attribute that has a URI of where to request all
> or create a new entry.  I believe there was a similar issue with a proposal
> that is not part of the spec.
>
> 3) Why is PUT not the way of updating the value of a single-value property?
>  I can see that POST could be used also.

That's a good question. I'm not sure I have a strong preference here.
What we are doing doesn't really fit POST or PUT as defined in the
HTTP spec.


> 4) Why is there no way specified to update multi-valued properties?
> There is one for multi-valued link properties.  Isn't a link just a type of
> a property value?  Why does it need to be treated special?

There is a way: you delete the old value and add the new value. We
have a short-cut for multi-valued links because it's easy to use the
property name and link value to uniquely identify the link.


> 5)  Efficient way to retrieve large multi-valued properties
> One of the motivating factors in creating the level of indirection in CM
> (aka @collref) was that we could apply pagination to these large collections
> of properties.  The common theme to these was that they contained links to
> other resources, like affected test cases or builds included in, etc.

I think this is the separate issue of partial fetch which could be
supported by allowing paging of resources and not just query results.


> 6) Deleting of one value from multi-valued properties
> Overall this is an improvement to what we did in CM but still not sure why
> this is restricted to property types of links.

It's restricted to links because there is an easy way to uniquely
identify link properties.

Thanks,
- Dave