RE: ATOM representation of search result facets

"Rushforth, Peter" <[email protected]>
Newsgroups gmane.comp.web.services.rest
Message-ID <1CD55F04538DEA4F85F3ADF7745464AF1AE4F490@S-BSC-MBX1.nrn.nrcan.gc.ca>
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.  If a client/processor is looking for the extended semantics
how does it request them?

> 
> 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

> 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.

> 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.  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.  


YMMV

Peter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.