Request for review of the application/ld+json media type

Hi,

The W3C has published a Last Call Working Draft of JSON-LD. I would thus
kindly ask you for feedback on the application/ld+json media type defined in
the specification:

http://www.w3.org/TR/json-ld-syntax/#iana-considerations

The text is included below.


Thanks,
Markus


----------------------------------------------

application/ld+json
Type name:
    application

Subtype name:
    ld+json

Required parameters:
    None

Optional parameters:
    profile
        A a non-empty list of space-separated URIs identifying specific
        constraints or conventions that apply to a JSON-LD document
        according [RFC6906]. A profile does not change the semantics of
        the resource representation when processed without profile
        knowledge, so that clients both with and without knowledge of a
        profiled resource can safely use the same representation. The
        profile parameter may be used by clients to express their
        preferences in the content negotiation process. It is RECOMMENDED
        that profile URIs are dereferenceable and provide useful
        documentation at that URI. For more information and background
        please refer to [RFC6906].

        This specification defines three values for the profile parameter.
        To request or specify Expanded JSON-LD document form, the URI
        http://www.w3.org/ns/json-ld#expanded SHOULD be used. To request
        or specify Compacted JSON-LD document form, the URI
        http://www.w3.org/ns/json-ld#compacted SHOULD be used. To request
        or specify Flattened JSON-LD document form, the URI
        http://www.w3.org/ns/json-ld#flattened SHOULD be used. Please note
        that, according [HTTP11], the value of the profile parameter has
        to be enclosed in quotes (") because it contains special
        characters and, if multiple profiles are combined, whitespace.

        When processing the "profile" media type parameter, it is
        important to note that its value is contains one or more URIs and
        not IRIs. In some cases it might therefore be necessary to convert
        between IRIs and URIs as specified in section 3 Relationship
        between IRIs and URIs of [RFC3987].

Encoding considerations:
    See RFC 6839, section 3.1.

Security considerations:
    Since JSON-LD is intended to be a pure data exchange format for
    directed graphs, the serialization SHOULD NOT be passed through a
    code execution mechanism such as JavaScript's eval() function to
    be parsed.

    JSON-LD contexts that are loaded from the Web over non-secure
    connections, such as HTTP, run the risk of modifying the JSON-LD
    active context in a way that could compromise security. It is
    advised that any application that depends on a remote context for
    mission critical purposes vet and cache the remote context before
    allowing the system to use it.

    Given that JSON-LD allows the substitution of long IRIs with short
    terms, JSON-LD documents may expand considerably when processed
    and, in the worst case, the resulting data might consume all of
    the recipient's resources. Applications should treat any data with
    due skepticism.

 Interoperability considerations:
    Not Applicable

Published specification:
    http://www.w3.org/TR/json-ld

Applications that use this media type:
    Any programming environment that requires the exchange of directed
    graphs. Implementations of JSON-LD have been created for
    JavaScript, Python, Ruby, PHP, and C++.

Additional information:
    Magic number(s):
        Not Applicable
    File extension(s):
        .jsonld
    Macintosh file type code(s):
        TEXT

Person & email address to contact for further information:
    Manu Sporny <msporny@digitalbazaar.com>

Intended usage:
    Common

Restrictions on usage:
    None

Author(s):
    Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler,
    Niklas Lindström

Change controller:
    W3C

Fragment identifiers used with application/ld+json are treated as in
RDF syntaxes, as per RDF 1.1 Concepts and Abstract Syntax 
[RDF11-CONCEPTS].



--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 16 April 2013 15:48:44 UTC