Subject: Fwd: Atom format interpretation question

From: Tim Bray <[email-masked]>
Date: Thu, 04 Jan 2007 20:22:30 -0800

Begin forwarded message:

> From: John Cowan <[email-masked]>
> Date: January 4, 2007 8:08:06 AM PST (CA)
> To: [email-masked]
> Subject: Atom format interpretation question
>
> Am I right in thinking that content which is in fact in XML but
> is labeled with a media type that is neither generic XML nor
> ends in "+xml" cannot be included inline in an Atom entry?
> The NewsML community (which uses the registered media-type
> text/vnd.IPTC.NewsML) is concerned about this.
>
> --  
> John Cowan  [email-masked]  http://ccil.org/~cowan
> Any sufficiently-complicated C or Fortran program contains an ad-hoc,
> informally-specified bug-ridden slow implementation of half of  
> Common Lisp.
>         --Greenspun's Tenth Rule of Programming (rules 1-9 are  
> unknown)

---

From: James M Snell <[email-masked]>
Date: Thu, 04 Jan 2007 20:56:29 -0800

If it's well-formed XML then I'd think dropping it into atom:content
using type="application/xml" would be acceptable.  You'd just end up
losing that bit of semantic metadata that tells you exactly what kind of
XML it is.  If you want to use the text/vnd.IPTC.NewsML media type to
identify the type of XML, then you'd have to escape the markup and treat
it like text.  If the NewsML folks want to be able to use a proper media
type to identify their stuff AND treat it as XML, they should come up
with an appropriate media type registration (e.g.
application/newsml+xml, etc).

- James

Tim Bray wrote:
>> -- John Cowan  [email-masked]  http://ccil.org/~cowan
>> informally-specified bug-ridden slow implementation of half of Common
>> Lisp.
>>         --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)
> 
> 
>

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 5 Jan 2007 03:27:13 -0500

On 1/4/07, James M Snell <[email-masked]> wrote:> If the NewsML folks
want to be able to use a proper
> mediatype to identify their stuff AND treat it as XML,
> they should come upwith an appropriate media type
> registration (e.g.application/newsml+xml, etc).

Did the "+xml" convention ever get formalized in some RFC? I know we all
*think* that tacking "+xml" onto the end of something means that it is some
use of XML, however, if I remember correctly, this little bit of syntax has
never actually been formalized... Or have I missed something? Is there an
RFC that defines what "+xml" means?

bob wyman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 05 Jan 2007 09:43:03 +0100

>RFC that defines what "+xml" means?

RFC 3023 and RFC 4288.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 5 Jan 2007 07:04:41 -0500

On 1/5/07, Bob Wyman <[email-masked]> wrote:
> On 1/4/07, James M Snell <[email-masked]> wrote:
> > If the NewsML folks want to be able to use a proper

http://www.ietf.org/rfc/rfc3023.txt

""This document also standardizes a convention (using
   the suffix '+xml') for naming media types outside of these five types
   when those media types represent XML MIME (Multipurpose Internet Mail
   Extensions) entities.""

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 05 Jan 2007 19:06:55 +0100

On Fri, 05 Jan 2007 05:22:30 +0100, Tim Bray <[email-masked]> wrote:

>> John Cowan wrote:

We've already discussed this in another thread, but since the question is  
asked in a different way here, I'd like to answer it again. John is partly  
right, but only because NewsML neither has a namespace nor an XML MIME  
type. If it had either, embedding it as XML in Atom would be no problem at  
all.

Thus, my conclusion is that this is a problem with NewsML and not with  
Atom.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 05 Jan 2007 19:10:06 +0100

On Fri, 05 Jan 2007 05:56:29 +0100, James M Snell <[email-masked]>  
wrote:

> If the NewsML folks want to be able to use a proper media type to  
> identify
> their stuff AND treat it as XML, they should come up with an appropriate
> media type registration (e.g. application/newsml+xml, etc).

- Or come up with an appropriate namespace URI. Both solutions work just  
as well imo, but I'd prefer both together over just one or the other,  
though. That is, both a new MIME type (that ends with '+xml') and a  
namespace URI.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 07 Jan 2007 07:46:29 -0500

James M Snell wrote:
> If you want to use the text/vnd.IPTC.NewsML media type to
> it like text.

s/escape/Base64/
s/like text/as binary/

- Sam Ruby

---

From: "James Holderness" <[email-masked]>
Date: Sun, 7 Jan 2007 14:46:35 -0000

>> identify the type of XML, then you'd have to escape the markup and treat

Are you sure? From RFC 4287, section 4.1.3.3:

5.  If the value of "type" begins with "text/" (case insensitive), the 
content of atom:content MUST NOT contain child elements.
6.  For all other values of "type", the content of atom:content MUST be a 
valid Base64 encoding, as described in [RFC3548], section 3.

In this case the type begins with "text/" so surely rule 5 applies, not rule 
6.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Sun, 07 Jan 2007 09:12:21 -0800

Ahhh... a slight ambiguity presents itself.  The treatment of text/
types in RFC 4287 is a bit underspecified.  I've always worked off the
assumption that text/* types do not require base64 encoding (that's what
Abdera expects).

- James

James Holderness wrote:
> 6.  For all other values of "type", the content of atom:content MUST be
> a valid Base64 encoding, as described in [RFC3548], section 3.
> 
> In this case the type begins with "text/" so surely rule 5 applies, not
> rule 6.
> 
> Regards
> James
> 
>

---

From: Sam Ruby <[email-masked]>
Date: Sun, 07 Jan 2007 17:05:56 -0500

> assumption that text/* types do not require base64 encoding (that's what

On second read, JamesH is right (as were you, originally); I was wrong.

I don't see the ambiguity.