Re: large categories documents

[James M Snell <jasnell@xxxxxxxxx>]

No it doesn't break the app:categories model but implementations need
to be aware of the paging links in order to use them... otherwise
those implementations will only ever see the one page of categories.
If you developed a model where that first page always contained the
most commonly used categories, then that may not be so much of a
problem in many cases.

On Fri, Apr 27, 2012 at 4:09 AM, Rushforth, Peter
<Peter.Rushforth@xxxxxxxxxxxxxxxxx> wrote:
> Relative to exposing a subset, would it not be possible to add a link@rel="next" to
> the actual application/atomcat+xml response at the discretion of the server?  While this
> would for current clients be like truncating the response, for hypermedia -aware clients
> it would be reasonable to fetch the next page.
> Does that break the app:categories model?  Is a feed a better way? As you say, you
> could then use atompub to manage the categories.  That's turtles, all the way down.
>
> I don't suppose it would hurt to add a profile link somewhere.  Where?
>
> I'm off to open the trout season.
>
> Cheers,
> Peter
> ________________________________________
> From: Erik Wilde [dret@xxxxxxxxxxxx]
> Sent: April 26, 2012 5:41 PM
> To: atom-protocol@xxxxxxx
> Cc: James M Snell; Rushforth, Peter
> Subject: Re: large categories documents
>
> hello.
>
> On 2012-04-26 20:47 , James M Snell wrote:
>> Indeed.. Regardless of how this is implemented, existing Atompub
>> clients are not going to understand it. The best we can do is
>> implement the extension with as little disruption as possible and
>> those implementations (client and server) for which this is useful and
>> necessary will adapt. The main point is, however, that the extension
>> can be implemented and deployed without making any changes to the
>> existing format, which should be a goal.
>
> i agree that the existing format should not be changed, and that
> existing clients should not break. but then we have to figure out how to
> best treat them: hide all categories, expose a subset (that would be
> sort of random, i guess), or come up with another strategy. starting
> from this, we could move forward and define an extension for "large
> category collection atompub", and clients supporting this profile (here
> goes my profile idea again) would have better ways of interacting with
> those larger sets of category values (and you could then also manage
> category collections through atompub, which i think might be fairly
> useful as well in some scenarios).
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@xxxxxxxxxxxx  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |