Re: ATOM representation of search result facets
Mark Baker <[email protected]>
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <CALcoZiqz60gik1PAhuP+L+o06Dxsffnxgi_oTJ+ok5uH6aAegQ@mail.gmail.com> |
Hey, On Wed, Sep 5, 2012 at 12:03 PM, Rushforth, Peter <[email protected]> wrote: > Hi Mark, > > Thanks for replying. > >> On Wed, Sep 5, 2012 at 8:09 AM, Rushforth, Peter >> <[email protected]> wrote: >> > My understanding is that application/atom+xml describes >> atom *without* >> > extensions. If you put extensions in, to *any media type*, >> via either >> > new markup or even changing the meaning of standard atom >> markup, you >> > should change media types, because it is the media type >> which names / >> > describes the preferred semantics of the message, and it is the >> > message metadata which is the most authoritative on the web: >> >> That's not the case. It may well be the case for some - >> text/plain comes to mind - but the majority of widely used >> media types are designed well enough to accommodate >> non-breaking extensions (where their introduction doesn't >> affect the meaning of the core content). > > IOW when served with that media type messages are understood as that > media type. Right. > If a client/processor is looking for the extended semantics > how does it request them? It doesn't, in general. If the extensions are standardized and have value to the publisher (usually determined by the quantity/quality of consumers), then the publisher will probably just provide them for everybody since they're not interested in dealing with the complexity of customizing responses for the specific needs of each client (again, in general). > >> >> That said, there's some ambiguity here with regards to when >> it makes sense to use a different (or new) media type. An SVG >> document wrapped in "<html><body>" wouldn't be very useful >> served with the text/html media type, for example. > > ??: http://www.w3schools.com/html5/html5_svg.asp Huh. Well, that example served me much better 10 years ago before compound document features percolated to the mainstream. Though the point remains for the moment, as I doubt all SVG clients are HTML5-enabled in this way, meaning that as an SVG publisher (and that sample document is, for all intents and purposes, SVG) I should still be using image/svg+xml. > >> But an >> Atom document with a single entry extension from a foreign >> namespace is still an Atom document because the spec >> specifically accommodates such an extension; it should use >> application/atom+xml. > > I agree that it _can_ use application/atom+xml, but in order > to convey extended semantics, paging for example, it would need to > use a different media type, application/atom+xml;type=feed in the > paging case. That's the same media type; application/atom+xml in both cases. The use of a media-type-specific parameter doesn't change the type. IIRC, James Snell wanted a separate media type for Atom feeds vs. entries and I came up with the compromise of the type parameter just so it could be safely ignored in this way (or perhaps somebody came up with it and I supported it, not sure). > >> In between those two extremes, the >> decision depends upon the specifics of the extensibility >> features of the >> type(s) in play, the importance and quantity of extended vs. >> core content. > > I don't think its a question of quantity, more of importance. And importance > is subjective. Agreed, but IME, there's usually a correlation with quantity. > If the extended semantics is important to a client, > it will be requested, with Accept:. If not, it won't. But if the > extended semantics is just served with no signals for desire or of > delivery, and clients actually do end up using the extended semantics, > that is out-of-band coupling of the nth degree IMHO. > >> >> Only the publisher knows what the content means, so they get >> to decide which media type to use. > > I believe that it is the published definition of the media type which is important, > not the content. A jpeg of my cat is not the same content as a jpeg of a supernova, > but they both may have the same media type definition. > > On the application tree, application/json or application/xml > would be sufficient for almost everything. But they aren't, so we invent new > media subtypes to describe the markup. Atom is one, but I don't think > it stops there, not by a long shot. Well, those two types aren't sufficient, but for different reasons than what I think you're talking about (search the archives for application/xml) Media types are not a type system of arbitrary granularity for your application, just a simple, very coarse-grained way to associate some content with a specification for its interpretation. You can of course define them as granular as you like, but the less general they are, the less appealing they are to support. Mark.