Re: [rest-discuss] REST and self-descriptiveness
- 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?
- -----BEGIN PGP SIGNED MESSAGE-----
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;
> 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
> 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-
> 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:
> 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...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----