Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] REST and self-descriptiveness

Expand Messages
  • Eric J. Bowman
    ... http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0385.html -Eric
    Message 1 of 49 , Sep 23, 2010
      Alan Dean wrote:
      > > Also interesting are IETF's reasons for rejecting the RFC for the
      > > Link header, for attempting to specify an XML-based IANA registry...
      > I'm not familiar with that - do you have a link?


    • Kris Zyp
      ... Hash: SHA1 ... Yes, that makes sense, I ll update the text for the next draft to try to have more appropriate language. ... - From that thread, it sounded
      Message 49 of 49 , Sep 24, 2010
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1

        On 9/24/2010 8:37 PM, Eric J. Bowman wrote:
        > Kris Zyp wrote:
        >> I guess maybe I misunderstood what you meant by processing model. If
        >> it is defined such it is not related to the expected data structures,
        >> hyperlink mechanisms and available relations, than it is indeed
        >> orthogonal to a schema. That's fine with me, sorry for any confusion.
        > What I mean is, you can't recommend doing this:
        > Content-Type: application/json;
        > profile=http://json.com/my-hyper-schema
        > Because when I look at the IANA registry, I see that application/json
        > maps to RFC 4627, which only lists one optional parameter, charset. I
        > see no definition of any profile parameter. The usage you are
        > recommending is not self-descriptive, because it is not supported by RFC
        > 4627.
        > One possible processing model for XHTML documents is text/plain, another
        > is text/html, and another is application/xhtml+xml -- please see RFC
        > 3236 as an example of how a media type registration is the proper place
        > to define such usage. RFC 3236 doesn't extend the definition of profile
        > to text/html, text/plain, or even application/xml -- this would be out-
        > of-scope.
        > If a standard comes along which registers application/foo+json, it is
        > up to that MIME registration to define the usage of a profile parameter.
        > Such a definition shouldn't have to worry about conflicting with some
        > other use of that syntax being forced on it by an unrelated spec, in
        > particular a schema spec which may have nothing whatever to do with the
        > schema (or BNF notation) being used to describe application/foo+json.

        Yes, that makes sense, I'll update the text for the next draft to try
        to have more appropriate language.

        > This usage is part of the processing model defined by the media type
        > identifier, it is not appropriate for a schema language to define such
        > usage for anything beyond, in this case, application/schema+json --
        > your media type registration for that identifier doesn't make sense, as
        > it doesn't define 'schema' or 'schema.items' and omits any mention of
        > the 'profile' parameter (again, see RFC 3236).
        > Don't get me wrong, I'm in favor of +json, I'm just giving the same
        > feedback that both schema+json and senml+json have gotten -- the right
        > way to do this is to first change RFC 4288, then RFC 4627:
        > http://www.ietf.org/mail-archive/web/ietf-types/current/msg01062.html
        > Otherwise, I don't see approval of either I-D until that issue is
        > settled or their associated identifier syntax is changed. But then
        > again, maybe it will be anyway, I don't know -- all I do know is that
        > no +json identifier has yet made it into the IANA registry, therefore no
        > +json identifier is currently self-descriptive; and that it is not self-
        > descriptive to use a profile parameter in conjunction with any media
        > type identifier unless that identifier defines a profile parameter.

        - From that thread, it sounded like everyone was in favor of making the
        updates. I wonder if that is being done by someone...

        - --
        Kris Zyp
        (503) 806-1841
        -----BEGIN PGP SIGNATURE-----
        Version: GnuPG v1.4.9 (MingW32)
        Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

        -----END PGP SIGNATURE-----
      Your message has been successfully submitted and would be delivered to recipients shortly.