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

From: "Rushforth, Peter" <[email-masked]>
Date: Mon, 14 Jan 2013 15:41:06 +0000

Hi Erik and Mark,

Why is the media type
 application/xml-patch and not something along the lines of application/xml-patch+xml ?

Thanks,
Peter Rushforth

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Jan 2013 07:44:10 -0800

Because xml-patch+xml is just silly? ;-)

To be serious, I have to assume that it's to maintain consistency with some
of the other patch formats that are on the table (e.g.
application/json-patch, application/json-merge-patch,
application/json-test-patch, etc)

- James

On Mon, Jan 14, 2013 at 7:41 AM, Rushforth, Peter <
[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Jan 2013 16:56:01 +0100

On 2013-01-14 16:44, James M Snell wrote:
> To be serious, I have to assume that it's to maintain consistency with
> some of the other patch formats that are on the table (e.g.

So for consistency with formats where we could ask the same question?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Mon, 14 Jan 2013 17:03:46 +0100

hello peter.

On 2013-01-14 16:44 , James M Snell wrote:
>> On Mon, Jan 14, 2013 at 7:41 AM, Rushforth, Peter
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>     Why is the media type

yes, that's the reason. for now, we have decided to follow this naming 
pattern of media types already under development. also, 
application/xml-patch+xml does indeed look a bit strange and doesn't buy 
you much (unless the "we should have a media subtype suffix registry" 
movement picks up steam). changing the media type's name of course would 
be trivial.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Erik Wilde <[email-masked]>
Date: Mon, 14 Jan 2013 17:15:58 +0100

hello julian.

> So for consistency with formats where we could ask the same question?

yes, that's one way to look at it. personally, i mostly care about a 
format and a name being defined and registered; what the name should 
look like is not absolutely essential. it would be nice, though, if 
patch formats would be named a bit consistently, and that's the 
motivation for the current name. i cannot remember seeing a debate 
around the other names, and maybe there should be one so that when RDF 
comes along with a patch model that can be serialized in a variety of 
ways, there's some guidance on how these ways should be named.

cheers,

dret.

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Jan 2013 08:47:09 -0800

Just a random thinking here... I've often thought that if there were a
critical mass of patch formats being developed, it would be interesting to
pursue a new top-level patch content type.. e.g. "patch/json",
"patch/json-merge", "patch/xml", "patch/text", "patch/octet-stream", etc.
Would seem to be a rather useful thing, really...

On Mon, Jan 14, 2013 at 8:15 AM, Erik Wilde <[email-masked]> wrote:

> format and a name being defined and registered; what the name should look
> like is not absolutely essential. it would be nice, though, if patch
> formats would be named a bit consistently, and that's the motivation for
> the current name. i cannot remember seeing a debate around the other names,
> and maybe there should be one so that when RDF comes along with a patch
> model that can be serialized in a variety of ways, there's some guidance on
> how these ways should be named.
>
>
> cheers,
>
> dret.
>
> --

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Jan 2013 11:33:29 -0800 (PST)

> movement picks up steam).

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.

				Ned

---

From: Erik Wilde <[email-masked]>
Date: Tue, 15 Jan 2013 09:26:50 +0100

hello ned.

> 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?

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.

thanks and cheers,

dret.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 15 Jan 2013 18:58:35 +0100

>right? in that case you'd recommend to go the xml-patch+xml way for the 

That sounds about right to me.

>targeted at a model, while the type's syntax is based on some specific 

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:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Jan 2013 10:36:42 -0800 (PST)

> right?

When it gets published is irrelevant. It's already approved as a standard
and specifies the current rules we operate under. The relevant IANA web
pages already cite it.

I'll note in passing that this use by IANA and others of documents that haven't
completed the publication process is not up to me; it's just how things work.

> in that case you'd recommend to go the xml-patch+xml way for the
> subtype, i guess?

Yes, that's what I would recommend, but really, it's not a question of what I
recommend. It's instead a question of what the standards require. I already
stated the requirements; if you believe you can make a compelling case for
omitting the suffix for this type you are free to do so.

> targeted at a model, while the type's syntax is based on some specific

That a question to be answered if and when someone proposes a suffix for rdf.
AFAIK there isn't one at present. I personally don't know enough about RDF and
how it is used to comment, although I'll note that the XML format has the
application/rdf+xml assigned. I will also note that EXI was considered and
rejected as a suffix.

				Ned

---

From: Erik Wilde <[email-masked]>
Date: Wed, 16 Jan 2013 09:48:58 +0100

hello bjoern.

thanks for the feedback.

> the specific type and without having to analyse any instance documents.

this opens up all kinds of interesting discussions. RDF currently uses 
application/rdf+xml, which to some extent is useful and correct (it's an 
XML-based syntax), but on the other hand using generic XML software on 
top of RDF/XML (apart from compression) is not very useful. but there 
very likely isn't a simple answer to this, since many data formats have 
more than just two layers these days.

> 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.

cheers,

dret.

---

From: Nicholas Shanks <[email-masked]>
Date: Tue, 22 Jan 2013 15:18:49 +0000

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

On 16 January 2013 08:48, Erik Wilde <[email-masked]> wrote:
> 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.