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

Mon Dec 6 18:57:27 EST 2010

Thanks.

The example I was looking for was pagination of JSON - I didn't see
anything at the link you referenced.

Actually my confusion about paginating JSON and HTML was cleared up by
Arthur, who suggested (and then contradicted <g>) what I think is an
elegant solution. Arthur's solution is to say that you do NOT paginate
representations, you paginate resources. Each page is a resource that
provides a portion of the information about another resource. Each page has
a representation, or representations, that follow the usual standards for
those media types, so there is no issue to resolve on how representations
are paginated. The server still has to decide how to paginate resources,
but since our model for resources is based on RDF, which is inherently
trivial to paginate, there is no problem.

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690

  From:       oslc-core-request at open-services.net                                                                                                     

  To:         oslc-core at open-services.net                                                                                                             

  Date:       12/06/2010 12:00 PM                                                                                                                     

  Subject:    Oslc-Core Digest, Vol 11, Issue 17                                                                                                      

  Sent by:    oslc-core-bounces at open-services.net                                                                                                     

Send Oslc-Core mailing list submissions to
             oslc-core at open-services.net

To subscribe or unsubscribe via the World Wide Web, visit

http://open-services.net/mailman/listinfo/oslc-core_open-services.net
or, via email, send a message with subject or body 'help' to
             oslc-core-request at open-services.net

You can reach the person managing the list at
             oslc-core-owner at open-services.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Oslc-Core digest..."

Today's Topics:

   1. Re: Oslc-Core Digest, Vol 11, Issue 1 (Dave)

----------------------------------------------------------------------

Message: 1
Date: Mon, 6 Dec 2010 11:11:04 -0500
From: Dave <snoopdave at gmail.com>
To: Martin Nally <nally at us.ibm.com>
Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
Subject: Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 1
Message-ID:
             <AANLkTikrEr1EJXvr566Hni6igOMBKpjO2X8hNxisd209 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

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

------------------------------

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

End of Oslc-Core Digest, Vol 11, Issue 17
*****************************************