[oslc-core] Oslc-Core Digest, Vol 11, Issue 1

[Dave]

Hi Martin,

Comments in-line below...


On Sat, Dec 4, 2010 at 7:29 PM, Martin Nally <nally at us.ibm.com> wrote:
> Dave writes:
>> Even if things have changed and client implementations (we know about)
>> can all now handle paging, it's pretty late in the spec process to be
>> making such a fundamental change.
>
> I don;t think we need to change the spec, but I think it would be useful to
> add something to give server writers more advice on what to do and thereby
> tell client writers what to expect. I think there are a few options:
>
> 1) Add a clarification that tells server implementers that they must do...
> 2) Add a clarification that says servers are allowed to decide to return...
> 3) Add a clarification that says that servers ca choose to do a 303...

After discussion in the work-group we decided to add some
clarification to the Core spec, explaining how a 302 redirect can be
used and how clients should behave. I added the clarification in a new
section called "Provider response-size limitations"
http://tinyurl.com/2dnfkfj


> Do we have opinions on how big is "too big", and whether we know that we
> already have use-cases that are "too big"? I got involved in this
> discussion when someone pointed out to me that one of the Rational products
> is doing a version of 2) when the change request queryBase is requested. If
> a queryBase had a million entries, its representation size would be a few
> megs. Is this "too big"?

I think this depends and could be different for different web
applications, sites, traffic levels, caching policies, etc.
Ultimately, as we've discussed, its up to the server.


>> Page is a better term, I agree, but we are very late in the game now
>> so I have the same question as above.
>
> Regardless of whether we tackle this rename now or later, I think the core
> spec would want to do this in a way that allowed backward compatibility.
> This would probably mean that oslc:Page would be introduced, but
> conservative servers would set both types to support old and new clients.
> Defensive clients would not pay any attention to the type at all, so they
> wouldn't care whether one, the other, both or neither were set. These
> clients would only look for the properties oslc:nextPage and
> oslc:totalCount. When I do examples, I often like to leave out the type
> altogether. Type does not add any meaning - it is just a "label" or "tag"
> that clients can look for, and there is usually something else you can use
> for the same purpose, like the existence of a property (from which the type
> can be inferred anyway, if you have an RDFS description for the property).
> Does the current spec say that the type must be set in a representation? If
> the spec doesn't already say explicitly that setting one or more values for
> type is mandatory, I'd vote for it remain optional. If the spec does say
> it's required, it's probably not worth changing.

Yes and spec actually says "A new version of an OSLC specification is
not allowed to introduce changes that will break old clients" so
changes must be additive. We can add a new "oslc:Page" but need to
keep oslc:ResponseInfo in place for old clients.


> There are some other renames that I think we should consider, that can be
> handled in a similar backwards-compatible way. An example of something I
> dislike is the current "?oslc:paging=true" syntax. In my opinion,
> ...

I captured your three rename suggestions on the issues page so they
will be considered with other deferred issues:
   http://open-services.net/bin/save/Main/OslcCoreV1Issues


>> The spec does explain how to paginate JSON using oslc:ResponseInfo and
>> oslc:nextPage.
>
> Thanks - I had missed this. I read the description, but found it hard to
> follow. Is there a worked example somewhere?

There is an example of oslc:ReponseInfo in the XML examples:
   http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples

Thanks,
Dave