W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2006

Re: Why not application/json?

From: Mark Baker <distobj@acm.org>
Date: Thu, 5 Oct 2006 11:00:41 -0400
Message-ID: <c70bc85d0610050800l1b9843cbvd4f71e4e92af82b5@mail.gmail.com>
To: "Elias Torres" <elias@torrez.us>
Cc: public-rdf-dawg-comments@w3.org

Hi Elias,

On 10/4/06, Elias Torres <elias@torrez.us> wrote:
> > I'm not sure what you mean by "model type".  Can you explain?
> I was trying to say that the JSON format does not provide any
> standard/best practice for content to be self-describing. If I parse a
> document of type application/json there's no way for me to find out the
> nature of the object structure I'm dealing within my application.

After having a detailed look at the examples in the spec, I understand
what you mean now.  I thought JSON's data model was richer than it
was.  I agree that a specific media type is appropriate.

> > I agree application/xml is insufficient for SPARQL results (and any
> > specific XML vocabulary in fact, for the reasons in the TAG finding on
> > authoritative metadata).  I don't agree that the same reasoning can be
> > applied to application/json though.
> I don't understand why the same reasoning doesn't apply to
> application/json. Could you give me any specific reasons for your
> disagreement?
> In authoritative metadata:
> "Superset media types being used when a more specific media type is
> intended, such as the use of "application/xml" when there exists a more
> specific media type corresponding to the root element."
> I would take this as a sign that more is better.

The appropriate media type depends entirely on the intent of the
sender; if, for example, the sender wants to send XHTML to be
interpreted as plain text, then text/plain is the appropriate media

But you wouldn't want or need, say, application/foaf+rdfxml or
application/sioc+rdfxml because FOAF and SIOC information can both be
expressed unambiguously using the RDF/XML spec.

Received on Thursday, 5 October 2006 15:00:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:07 UTC