Re: [apps-discuss] proposal: adding profile support to JSON

[Mark Baker <[e-mail]>]

Hi Erik,

On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde <[e-mail]> wrote:
> hello mark.
>
>
> On 2013-11-05, 08:59 , Mark Baker wrote:
>>
>> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray <[e-mail]> wrote:
>>>
>>> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html
>>
>> I'm with Martin. What that spec is trying to do with profiles is to
>> supplant the typical role of a media type. If it's representative of
>> what Erik has in mind for the use of a profile parameter with Atom (or
>> anywhere), then I think that needs to be reconsidered too.
>
>
> i understand your concerns, but profiles do not attempt to "replace media
> types", even though they could be (mis-)used to try to do just that. [1]
> tries to explain the goal: they are for specializing and/or constraining
> existing media types; representing both the nature of the underlying type
> ("this is an atom feed and can be processed as a generic feed") as well as
> the specialized/constrained profile ("this feed carries podcast data, and
> can be processed as a podcast feed").

I've read your RFC, and both referenced blog posts, but still find
myself asking the same question; what problem does it solve? Yes,
media types have their issues, but in my many years in Web development
and standardization, I've yet to encounter a problem that didn't have
a workable solution through the correct use of link relations and
media types. This includes my time advising on the development of a
compound document editor at Justsystem, and representing them on the
W3C Compound Document Formats WG.

We agree that a document containing some OPDS extensions is still an
Atom document that can be delivered as application/atom+xml, I
believe. You appear to suggest that there's value in exposing the
existence of those OPDS extensions using an additional external
metadata protocol element. I believe that this is at best an
optimization, since the consumer can easily detect the existence of
the extension by inspecting the content (and understanding the
extensibility model of the host format). But at worst, it's a recipe
for interop problems; does the meaning of the document change if the
profile is declared vs not? What if the v2 profile URI is declared and
the document contains a v1 extension? etc..

This really smells to me like a solution in search of a problem.

> james snell blogged about the bigger problem [2] that media types as they
> are today are not a terribly well-designed concept.

I strongly disagree with that post (blog commenting seems broken, but
I won't respond in detail here except to say "rel=icon" :). I believe
media types are far better designed than is commonly appreciated; a
single label for a compatible evolution of a document format is a
simple yet extremely powerful protocol that promotes compatibility in
extensions and penalizes incompatible deviations... but still permits
them when required.

And FWIW, this is coming from the guy who, AFAIK, started the whole
profile parameter ball rolling in RFC 3236. That went in there only as
a compromise with the WAPforum, but was never/rarely used in practice.