Re: [apps-discuss] New Version Notification for draft-wilde-xml-patch-00.txt

[Nicholas Shanks <[e-mail]>]

[Cross-posting to HTTP WG since my brain dump affects them too]

On 16 January 2013 08:48, Erik Wilde <[e-mail]> wrote:
> On 2013-01-15 18:58 , Bjoern Hoehrmann wrote:
>> If someone made a format that expresses differences between "RDF files"
>> or some sort, and that format is based on JSON, the argument would most
>> likely be to use +json for the corresponding media type.
>
> my point was more that an RDF patch format more likely would patch the RDF
> model, and not a specific RDF syntax. thus, it might use "rdf-patch" as the
> starting point, but then the patch format itself probably would be defined
> as RDF, and thus could be serialized in different ways, so that we might
> have rdf-patch+rdfxml and rdf-patch+turtle, if there were specific suffixes
> for different RDF serializations. this is all hypothetical right now as
> there aren't any RDF suffixes, but i was wondering whether this would be the
> direction all of this would move towards.

The best solution to this mess, in my opinion, would be to adopt
Universal Type Identifiers[1] as a replacement for MIME types across
the internet. During a transitional period, both will have to be
present, but I'm hopping that shouldn't be too much of a burden (see
below for why not). Eventually Apple ought to transfer control of the
public.* registry to the IETF too, but that's a bridge that can be
crossed at a later date.

In short, the benefits of UTIs over MIME types are that you get
multiple inheritance and don't have to stuff all of the inheritance
hierarchy into one label.
RDF Patch inherits from RDF, RDF inherits from XML in one
serialization, and XML inherits from Plain Text. In MIME parlance that
ought to be text/rdf-patch+rdf+xml, and that syntax only allows a
single inheritance chain. Multiple inheritance can be useful in
selecting alternative software to edit a resource.
The draw-backs to using UTIs are that clients have to be smarter: they
have to have advance knowledge of the public.* hierarchy and the
inheritance paths of any custom types which they can handle.

Since forward slashes are prohibited in UTIs, a MIME type and a UTI
can be crudely distinguished by the presence or absence of this
character. It may be possible therefore to permit multiple values for
the Content-Type header such as "text/html, public.html" without
confusing clients and intermediaries. I'd prefer that to inventing a
new HTTP header, since the semantics being conveyed are identical.

Before any of this can become a possibility though, the HTTPbis WG
should specify in p2 section 3.1.1.5, that all clients must split the
Content-Type header into constituent values per the rules for doing
so, then ignore but retain any header values which it does not
understand (with their attendant parameters, if any). Clients can then
use their own heuristic in determining what type to process a resource
as. This could even allow headers such as "Content-Type:
application/rdf-patch, application/rdf, application/xml, text/plain"
as a way of providing a type hierarchy to clients. It makes sense to
list more precise types first, but ordering should not matter to
clients that are multi-value aware. Very dumb clients can just chop at
the first comma, leaving us with what we have presently.

[1] read some of the results from
https://www.google.com/search?q=apple+uti for more info

-- 
Nicholas.