I like where you are going with this. I have a few comments, clarifications, and questions:
One thing I really like about the direction we appear to be heading in is that it doesn't require a change to the core spec. Instead we would offer a clarification/extension that explains what a server should do if it wants to initiate pagination. The spec already explains what clients need to do. If the server wants to initiate paging, it could reply with a 302 or 303 redirect, or it could just go ahead and return the first page. Both seem reasonable - the following link describes and implicitly endorses both techniques for selecting a representation based on language - http://www.w3.org/TR/cooluris/#conneg. Selecting non-paginated or paginated representations based on size is a different case from selecting the appropriate language representation based on the accept-language header, but the analogy seems reasonable. Using a 302 or 303 redirect seems very "classic" to me - it seems very harsh to try forbid its use. If we allow its use, well-behaved clients have to anticipate the possibility and code for it. Would you recommend forbidding the server from using redirect, even though it's a common and valid solution for these sorts of cases? This question is actually broader than the current topic of pagination - in the real web, servers can use redirects whenever they see fit, as described in the link above. The core spec should probably say whether or not OSLC clients need be ready for this. My first thought is that they do. 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. 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. 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. 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. Frank Budinsky pointed out that the sequence of pages is a collection, and that RDF already has a vocabulary for collections. This would suggest that we do not need oslc:nextPage - we can use rdf:next instead. Regardless of whether or not we drop oslc:nextPage, Frank also points out that it would be more consistent with precedent if the collection was terminated with a value of rdf:nil for next(Page), rather than absence of the property. Best regards, Martin Martin Nally, IBM Fellow CTO and VP, IBM Rational tel: +1 (714)472-2690 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Arthur Ryman/Toronto/IBM@IBMCA | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Martin Nally/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |11/26/2010 09:57 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: Fw: [oslc-core] Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo | >--------------------------------------------------------------------------------------------------------------------------------------------------| Martin, I actually like this alternative. I have some comments. There are really two different reasons why paging might occur 1) the client has limitations, 2) the server has limitations. The core spec only is explicit about the client limitations. If a client does not request paging, and the result exceeds the server limits, then there are two alternates - the request can fail, or the server can return partial results and a link to the rest. I think we'd agree that the later is more friendly and has precedents. Atom works that way, and so does Insight since it copies Atom. In both cases there is a specified way to link to the next page without the client initiating a paging request. I think our spec should be more explicit, i.e. a client SHOULD always check for an oslc.nextPage property. If we adopted this, then we wouldn't need the redirects. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE (Embedded image moved to file: pic32000.gif) Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Martin Nally/Raleigh/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Arthur Ryman/Toronto/IBM@IBMCA | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |11/25/2010 08:35 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Fw: [oslc-core] Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo | >--------------------------------------------------------------------------------------------------------------------------------------------------| I do not believe that the problem with the core spec that you describe exists. I think the core spec is fine in this area and should be left alone - I think the current design is superior to the one you propose. Your description says that the problem arises when the user requests http://example.org/bugs, and the server decides to respond with only the first page. In the model upon which the core spec is based, this can't happen. "The list of bugs" and "the first page of the list of bugs" are two different concepts and are thus two different resources with two different URLs, and the server does not have the right to respond with the representation of one when the other was requested. The URL for "the first page of the list of bugs" is clearly specified in the core spec - it is http://example.org/bugs?oslc.paging=true. Although the server may not respond with "the first page of the list of bugs" when the client asked for "the list of bugs", it might be acceptable for the server to perform a 302 (or 303) redirect if it decided that the requested resource is too big to return. An argument against this would be that it is unfriendly to surprise a client that may not understand paging in this way, but on the other hand, returning an unworkably large representation might be worse and so the redirect might be the lesser of two evils. If the server did perform a redirect to http://example.org/bugs?oslc.paging=true, a subsequent GET on that URL would produce the following representation according to the current core spec design: <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc=" http://open-services.net/ns/core#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> <rdf:Description rdf:about="http://example.org/bugs";> <dcterms:title>Bug List</dcterms:title> <rdfs:member rdf:resource="http://example.org/bugs/1"; /> <rdfs:member rdf:resource="http://example.org/bugs/2"; /> <!-- etc. --> <rdfs:member rdf:resource="http://example.org/bugs/1000 "/> </rdf:Description> <oslc:ResponseInfo rdf:about=" http://example.org/bugs?oslc,paging=true";> <dcterms:title>Bug List - Page 1</dcterms:title> <oslc:totalCount>10000</oslc:totalCount> <oslc:nextPage rdf:resource=" http://example.org/bugs/pages/2"; /> </oslc:ResponseInfo> </rdf:RDF> As you can see there is no problem because the two dcterms:title triples have different subjects. Best regards, Martin |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Arthur Ryman/Toronto/IBM@IBMCA | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |11/23/2010 12:47 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[oslc-core] Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Sent by: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |[email protected] | >--------------------------------------------------------------------------------------------------------------------------------------------------| While reviewing an implementation I noticed that dcterms:title and dcterms:description can be used with oslc:ResponseInfo. This can lead to confusion in the case of requesting a any resource, since that resource itself may use those properties. The resource URI of the first page of a multi-page response is the same as the URI of the resource itself. For example, suppose we have a resource that is a list of bugs and that it has the dcterms:title "List of Bugs". Suppose it contains 10,000 bugs, and this is too much to return in one response. This resource is like: <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc=" http://open-services.net/ns/core#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> <rdf:Description rdf:about="http://example.org/bugs";> <dcterms:title>Bug List</dcterms:title> <rdfs:member rdf:resource="http://example.org/bugs/1"; /> <rdfs:member rdf:resource="http://example.org/bugs/2"; /> <!-- etc. --> <rdfs:member rdf:resource="http://example.org/bugs/10000"; /> </rdf:Description> </rdf:RDF> Suppose the service will only return 1,000 or less bugs per response. When you get the bug list URI, the response therefore gets paged. The OSLC Core spec says that the first page looks something like: <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc=" http://open-services.net/ns/core#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> <rdf:Description rdf:about="http://example.org/bugs";> <dcterms:title>Bug List</dcterms:title> <rdfs:member rdf:resource="http://example.org/bugs/1"; /> <rdfs:member rdf:resource="http://example.org/bugs/2"; /> <!-- etc. --> <rdfs:member rdf:resource="http://example.org/bugs/1000"; /> </rdf:Description> <oslc:ResponseInfo rdf:about="http://example.org/bugs";> <dcterms:title>Bug List - Page 1</dcterms:title> <oslc:totalCount>10000</oslc:totalCount> <oslc:nextPage rdf:resource=" http://example.org/bugs/pages/2"; /> </oslc:ResponseInfo> </rdf:RDF> The issue here is that now there are two dcterms:title triples associated with the subject node <http:example.org/bugs>, which is confusing since the second one (a child of the oslc:ResponseInfo element) is really the title of the response. I can see two fixes. I prefer fix 1 since it cleanly separates the response info from the request result data. 1. (Preferred) Introduce another property, e.g. oslc:request to identify the request URI, and use a blank node for oslc:ResponseInfo. The result is now: <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc=" http://open-services.net/ns/core#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> <rdf:Description rdf:about="http://example.org/bugs";> <dcterms:title>Bug List</dcterms:title> <rdfs:member rdf:resource="http://example.org/bugs/1"; /> <rdfs:member rdf:resource="http://example.org/bugs/2"; /> <!-- etc. --> <rdfs:member rdf:resource="http://example.org/bugs/1000"; /> </rdf:Description> <oslc:ResponseInfo> <oslc:request rdf:resource="http://example.org/bugs"; /> <dcterms:title>Bug List - Page 1</dcterms:title> <oslc:totalCount>10000</oslc:totalCount> <oslc:nextPage rdf:resource=" http://example.org/bugs/pages/2"; /> </oslc:ResponseInfo> </rdf:RDF> 2. Use different properties for title and description, e.g. oslc:responseTitle, oslc:responseDescription <rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:oslc=" http://open-services.net/ns/core#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> <rdf:Description rdf:about="http://example.org/bugs";> <dcterms:title>Bug List</dcterms:title> <rdfs:member rdf:resource="http://example.org/bugs/1"; /> <rdfs:member rdf:resource="http://example.org/bugs/2"; /> <!-- etc. --> <rdfs:member rdf:resource="http://example.org/bugs/1000"; /> </rdf:Description> <oslc:ResponseInfo rdf:about="http://example.org/bugs";> <oslc:responseTitle>Bug List - Page 1</oslc:responseTitle> <oslc:totalCount>10000</oslc:totalCount> <oslc:nextPage rdf:resource=" http://example.org/bugs/pages/2"; /> </oslc:ResponseInfo> </rdf:RDF> 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 _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
