[oslc-core] Oslc-Core Digest, Vol 11, Issue 17
Arthur Ryman
ryman at ca.ibm.com
Wed Dec 8 12:07:47 EST 2010
Martin,
Although any resource may have multiple representations, some resources
may only have one representation. In the case of paging, I think it makes
sense to allow the page contents and breaks to depend on the
representation initially selected. Different representations will differ
in their compactness, e.g. one page of Turtle might take 10 pages of HTML.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
From:
Martin Nally <nally at us.ibm.com>
To:
oslc-core at open-services.net
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
12/06/2010 07:02 PM
Subject:
Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 17
Sent by:
oslc-core-bounces at open-services.net
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
*****************************************
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list