[oslc-core] Oslc-Core Digest, Vol 11, Issue 1
Martin Nally
nally at us.ibm.com
Sat Dec 4 19:29:37 EST 2010
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
what the client asked, even if it doesn't seem like a good idea. When the
client asks for the resource, return the full representation of the
resource, even if it's big. Clients will learn not to do it again if it's
too big. If it's so big that it's not even possible to try to return it,
then we have screwed up the definitions of the resources, and the spec
should not try to work around this with more options - we should change the
definitions of the resources.
2) Add a clarification that says servers are allowed to decide to return
the first page (which is a different resource from the one requested) when
asked for a resource. Explain to server implementers how to do this
"correctly" and warn clients it may happen.
3) Add a clarification that says that servers ca choose to do a 303
redirect if the resource representation is too big. Clients need to expect
this result, but do not need to follow the redirect if they don't want to.
Even if we don't recommend this option for this case, the OSLC spec should
probably say more generally whether or not a GET to an OSLC server may
result in a redirect.
The most conservative approach is to do 1). I would personally be fine with
this.
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"?
> 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.
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,
"?oslc:paging=true" is not compatible with a REST. "?oslc:pagination=true"
is not simply naming a concept/resource, as you should in REST, it is
adding a conceptual "qualifier" to a base URL. Qualifiers like this are not
part of the REST/Linked-data conceptual model. A better RESTful syntax
would have been "?oslc:firstPage", so instead of
http://vh1.example.com/changeRequests?oslc:pagination=true
which conceptually adds a qualifier to
http://vh1.example.com/changeRequests, which is the URL of a resource, you
would write
http://vh1.example.com/changeRequests?oslc:firstPage
which is just the URL of a resource.
A third rename I think we should debate, at least, is deprecating
oslc:nextPage in favor of rdf:next. I'm guessing there are arguments
against (as well as for) doing this - the discussion will be interesting.
> 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?
Best regards, Martin
Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690
oslc-core-bounces at open-services.net wrote on 12/01/2010 12:00:19 PM:
> [image removed]
>
> Oslc-Core Digest, Vol 11, Issue 1
>
> oslc-core-request
>
> to:
>
> oslc-core
>
> 12/01/2010 12:00 PM
>
> Sent by:
>
> oslc-core-bounces at open-services.net
>
> Please respond to oslc-core
>
> 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. REMINDER: OSLC Core WG meeting tomorrow 10am US/ET (Dave)
> 2. Re: REMINDER: OSLC Core WG meeting tomorrow 10am US/ET
> (Arthur Ryman)
> 3. Re: Fw: Issue with the Use of dcterms:title and
> dcterms:description with oslc:ResponseInfo (Dave)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Nov 2010 16:42:11 -0500
> From: Dave <snoopdave at gmail.com>
> To: oslc-core <oslc-core at open-services.net>
> Subject: [oslc-core] REMINDER: OSLC Core WG meeting tomorrow 10am
> US/ET
> Message-ID:
> <AANLkTimgwEYuuiyrQYC51z31_Y8_M9FbrWvkrP83x6MT at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> We will have a Core WG meeting tomorrow Wednesday December 1 at 10AM
> US/ET. Here's the info:
>
> Agenda:
> http://open-services.net/bin/view/Main/OslcCoreMeeting20101201
>
> If you have additional agenda items, please speak up.
>
> Telecon:
> * Participant passcode: 558663
> * Toll free: 1-866-423-8350
> * Toll: 1-719-387-8273
>
> Online meeting:
> * For people outside IBM
> https://www.lotuslive.com/join?schedid=4446009
> * For IBM employees
> https://wedc.lotus.com/meeting/join/?schedid=4446009
> (IBM intranet authentication required)
>
> Thanks,
> Dave
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 30 Nov 2010 18:28:35 -0500
> From: Arthur Ryman <ryman at ca.ibm.com>
> To: Dave <snoopdave at gmail.com>
> Cc: oslc-core <oslc-core at open-services.net>,
> oslc-core-bounces at open-services.net
> Subject: Re: [oslc-core] REMINDER: OSLC Core WG meeting tomorrow 10am
> US/ET
> Message-ID:
> <OFBBF9534D.3C4EC5DA-ON852577EB.0080D639-852577EB.0080F742 at ca.ibm.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> Dave,
>
> I cannot attend the telecon due to a dev mtg conflict.
>
> 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:
> Dave <snoopdave at gmail.com>
> To:
> oslc-core <oslc-core at open-services.net>
> Date:
> 10/26/2010 04:57 PM
> Subject:
> [oslc-core] REMINDER: OSLC Core WG meeting tomorrow 10am US/ET
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
> We will have a Core WG meeting tomorrow Wednesday October 27 at 10AM
> US/ET. Here's the info:
>
> Agenda:
> http://open-services.net/bin/view/Main/OslcCoreMeetings20101027
>
> If you have additional agenda items, please speak up.
>
> Telecon:
> * Participant passcode: 558663
> * Toll free: 1-866-423-8350
> * Toll: 1-719-387-8273
>
> Online meeting:
> * For people outside IBM
> https://www.lotuslive.com/join?schedid=4446009
> * For IBM employees
> https://wedc.lotus.com/meeting/join/?schedid=4446009
> (IBM intranet authentication required)
>
> Thanks,
> Dave
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 1 Dec 2010 09:50:41 -0500
> From: Dave <snoopdave at gmail.com>
> To: oslc-core at open-services.net
> Cc: Martin Nally <nally at us.ibm.com>
> Subject: Re: [oslc-core] Fw: Issue with the Use of dcterms:title and
> dcterms:description with oslc:ResponseInfo
> Message-ID:
> <AANLkTimUFGXtoZpuBWHsO7c2jAnp_JSMM-Mwh9gvsb+z at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Thanks for pointing out the error of our ways. I think that we all
> forgot paging is optional and must be requested by the client. More
> comments below.
>
>
> On Fri, Nov 26, 2010 at 8:22 PM, Martin Nally <nally at us.ibm.com> wrote:
> > Regardless of the answer to the question on 302/303 redirects, I like
your
> > suggestion that the server should be allowed to return the first page
in
> > response to a GET on the whole list (contrary to what I originally
wrote).
> > If we allow this, I would like us to mandate that the server provide a
> > content-location header in the response that indicates that the
resource
> > that was returned is in fact
http://example.org/bugs?oslc:pagination=true,
> > not http://example.org/bugs. This gives the client two ways to
recognize
> > what just happened - it can notice that the resource returned is
different
> > from the one requested, or it can look for a nextPage property in the
> > representation. More generally, it provides the client with a specific
> > indicator of the "implicit redirect" that happened on the server
without
> > having to guess based on the representation. When we get our
verification
> > test suite going, it should check for this.
>
> We required clients to ask for paging via oslc.paging=true because we
> had lots of feedback from implementation teams telling us that clients
> could not handle paging. We removed it and other features (e.g. in
> query syntax) because we were under pressure to simplify the spec.
>
> 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.
>
> Do we have a handle on the impact to existing implementations and can
> we tolerate it?
>
>
> > Several people have noted that the term "ResponseInfo" does not fit the
> > conceptual model currently documented in the spec. I think this term is
may
> > be a relic a different conceptual model that was previously proposed
and
> > discarded. Any chance we can change the name to match the model? Page
would
> > be the obvious choice of term.
>
> Page is a better term, I agree, but we are very late in the game now
> so I have the same question as above.
>
>
> > RDF representations lend themselves very nicely to pagination, because
an
> > RDF graph has no structure - it's just a set of triples, so is easy to
> > break into subsets. Some other representations, like HTML, are much
harder
> > to paginate, and in fact I find it hard to imagine a satisfactory way
to
> > paginate HTML (maybe 2 pages - one with the head and one with the
body).
> > JSON might also be tricky to paginate. Is pagination only expected to
work
> > with RDF? If so, the spec should say so - I didn't find anything when I
> > looked. If pagination is expected to work with other formats like JSON,
I
> > think the spec needs explain how to paginate them.
>
> The spec does explain how to paginate JSON using oslc:ResponseInfo and
> oslc:nextPage.
>
> http://tinyurl.com/3yxuxvz - or -
> http://open-services.net/bin/view/Main/
> OSLCCoreSpecAppendixRepresentations#Guidelines_for_JSON
>
>
> > It's not clear what totalCount refers to. Is it simply the number of
> > triples? The spec says "the number of results", which is a bit vague. I
> > think we should clarify.
>
> Yes, this should definitely be clarified. I'll get it on the work-
> group agenda.
>
> 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 1
> ****************************************
More information about the Oslc-Core
mailing list