Fwd: [p3-payload] Media-Type -- Two Values, One Cup Anti-Pattern?

Maybe discussion out band is less apt to receive a response?

...and does anyone else have any thoughts in this area?  Am I talking
nonsense?  Or is everyone just scared to gainsay Dr. Fielding?  ;-)

To summarize my position:

Two+ values in one cup/bucket/variable/column/header is bad.

The best place for catch-alls like that are when one cannot anticipate the
required types (like say...when you're first writing a spec/api).  We now
know the sort of instructions most Media Types dictate.

Since all Media Type processing instructions constrain the format.  We
could all greatly benefit from format (syntactic type) (and maybe datatype
(semantic type)) being divorced from the other less uniform processing
instructions.

How would one add that to an existing protocol though?  Addition to the
existing spec?  New RFC?

-Ray

(btw - I don't mean to be negative.  I'm a huge REST/Fielding & HTTP
fanboy.  I just think this aspect may be able to benefit from an update.)

---------- Forwarded message ----------
From: Ray Polk <raypolk@gmail.com>
Date: Tue, Jan 17, 2012 at 3:34 PM
Subject: Re: [p3-payload] Media-Type -- Two Values, One Cup Anti-Pattern?
To: "Roy T. Fielding" <fielding@gbiv.com>




On Tue, Jan 17, 2012 at 2:54 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Jan 17, 2012, at 1:27 PM, Ray Polk wrote:
>
> > My concern was with the ramifications of including data semantics in the
> processing mechanism along with the format information.
>
> I understood that.  However, that concern left the barn some 20 years ago.
>

Oh to be 20 years older (how often do you hear that? :D )


> > By combining the two, the number of total registered types can/could
> increase geometrically.  The vnd.openxmlformats-*+xml formats are an
> example of that potential.  Imagine if someone registers openjsonformats &
> openyamlformats.  Then they want both text and binary formats.  The list of
> ~75 types at the end of this email becomes 400+.
>
> They could, but in practice they don't.  The reason is simply that getting
> people to agree on a common processing mechanism to use on receipt of a
> message is much harder than registering a type.
>

I would posit that it's not done more because it's a bad idea.  The fact
that it's relatively easy to register a type probably leads to spurious
types more than it suppresses them.


> > Now imagine the growth as such a practice spreads to other domains AND
> as the number of popular text formats grows...
> >
> > Endpoints and clients dealing with format+datatype media types would be
> repeating themselves over and over again.  Imagine the Accept headers...
> >
> > To put it another way, can I register vnd.cat-jpeg? :-)  Should I?
>
> If you have a need for the recipient to process that type is a way
> that is different than how they would normally process jpeg, then
> the answer is yes.  For example, text/html and text/plain are two
> different ways to process the same data.
>
> > Sure, a design that allows endpoints to supply user agents a key to
> lookup processing instructions maximizes flexibility.  Catch-all text
> columns, member variables and void pointers all also maximize flexibility.
> >
> > When in practice, though, ~100% of those catch-alls include format
> information.  Isn't it time for a more strongly typed header/column/member?
>  (to go along witth the catch all)
>
> The format information is not the most significant information needed
> by the recipient in order to process a MIME message.  While someone
> could come up with a better design, I suppose, it is certainly not
> within scope for HTTPbis.


Can you suggest a better forum for such a discussion?  A better vehicle for
such an effort?

Regardless, since the exact same sequence
> of octets *is* processed differently depending on the media type metadata,
> it is fair to say that format information is not the key concern even
> if most data formats have a type named after them.
>

Are you referencing your text/html & text/plain example above?  The format
information is THE key.  It dictates the two methods of processing the
data.  The fact that they both apply to the same bits is simply an artifact
of text/xml being a subtype of text/plain.

To prove your point, you'd need the same bits being processed differently
due to instructions _other_ than format; not because of the format.


>
> ....Roy
>
>