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

[mike amundsen <[e-mail]>]

<snip>I've read your RFC, and both referenced blog posts, but still find
myself asking the same question; what problem does it solve?</snip>

Mark:

I use profiles to _add_ domain-specific information to an existing
hypermedia format (like HTML or Collection+JSON).

Separation of Concerns
This makes it possible to separate protocol details (HTTP) from domain
details (accounting, microblogging) which make re-use of existing media
types possible even when you encounter a new problem domain.

Decoupling & Reuse
Using profiles also creates a "closed world" model of a domain (e.g.
microblogging) and that makes it possible to code a client all that
recognizes that domain *independent* of the media type.  This speeds/eases
the effort to create an M2M domain client since you are working in "layers"
you can take an existing hypermedia type (e.g. HTML) parser and _add_ the
domain-specific coding.

IMO, this is solving a problem that existing now and will continue to
exist. It offers the ability for developers to "level-up" and stop coding
protocol and focus on domain specifics *without* losing fidelity to a
protocol.





mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mamund


On Wed, Nov 6, 2013 at 9:20 AM, Mark Baker <[e-mail]> wrote:

> 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.
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>