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

[Bjoern Hoehrmann <[e-mail]>]

* Erik Wilde wrote:
>On 2013-01-14 20:33 , Ned Freed wrote:
>> Since in fact we do have such a registry now, you can take that as given.
>> And the use of the suffix is now a SHOULD; you can only not do it if you
>> have a
>> very good reason for that choice. I personally don't think that name
>> consistency with other types is even close to rising to that level; YMMV.
>
>http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-08 
>is what you're referring to and this one is going to get published soon, 
>right? in that case you'd recommend to go the xml-patch+xml way for the 
>subtype, i guess?

That sounds about right to me.

>i am really wondering how this is going to play out for RDF, have their 
>been discussions on how to handle this case (multiple serializations of 
>the same data model) for the suffix registry? the reason why i am asking 
>is that RDF needs a patch type as well, and there it will become an 
>issue how to handle the fact that usually, a patch type's semantics are 
>targeted at a model, while the type's syntax is based on some specific 
>serialization.

That does not seem very relevant to the suffix registry. The logic here
is that XML formats should use +xml types so "generic" applications can
recognize XML content more easily and more reliably, for instance, so a
program can offer the user the option to edit such a document in an XML
editor, or a web server might decide to compress the content on transfer
because XML content is known to compress well, without having to know
the specific type and without having to analyse any instance documents.

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.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/