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

[Mark Baker <[e-mail]>]

Hi Erik,

On Wed, Nov 6, 2013 at 1:35 PM, Erik Wilde <[e-mail]> wrote:
> hello mark.
>
>
> On 2013-11-06, 06:20 , Mark Baker wrote:
>>
>> 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.
>
>
> as i am sure you know, "profile" is a link relation. so what you're saying
> that it's not a "correct" use of link relations? i am really just trying to
> understand your perspective here. a profile media type parameter just
> exposes that link relation in a special place, because it matters for the
> media type, and it is more convenient to see it exposed there, instead of
> first having to parse the representation.

Yes, I wasn't trying to single out "profile" at all, just speak to the
general utility of type/rel.

>> You appear to suggest that there's value in exposing the
>> existence of those OPDS extensions using an additional external
>> metadata protocol element.
>
>
> yes, because then profiles can, for example, take part in wen-level
> mechanisms such as conneg, instead of being "hidden" only in the
> representations.

...

>> 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).
>
>
> true for reading, not true for writing, where profiles can also indicate
> what constrained media types a server is willing to accept.

Ok. But AFAICT, the I-JSON draft isn't using profile=i-json as an
optimization. IMO, if it needs for the "urn:ietf:i-json" key to have
special meaning, media types are the only way we currently have to
communicate that fact to JSON recipients (over HTTP at least). But I
have to admit to not understanding the context for I-JSON's existence,
not being involved in those discussions, so perhaps I'm missing
something. Regardless of the specifics of that example, my general
concern is that what you admit is an optimization for these types of
scenarios, may be misunderstood as being something more than that (as
James' suggests when he talks about it eventually replacing media
types).

If your claim is that the true value for profiles is elsewhere, I'd
like to see a concrete proposal before we begin to standardize on
protocol elements for their use. I'm personally skeptical (I'm sure
you're shocked to hear this :) as I've put considerable effort into
exploring this space over the years (including lots of test case
code).

See http://www.markbaker.ca/Talks/2004-media-types-and-compdocs/slide1-0.html
which Markus might also be interested in, to explain why XML
namespaces don't do what he claims. W3C members might also be
interested in the strawman proposal motivated by that presentation;
https://lists.w3.org/Archives/Member/member-cdf/2006Apr/0000.html