I read 4.1.3.3 (reinforced by the point in 4.1.2 that explains when atom:summary is required) as:
The content of atom:content is encoded as base64 if and only if the media type is a MIME type that is not of the form */xml nor */*+xml nor text/*.
Florent
On 24 Jul 2009, at 18:48, Al Brown wrote: Please see http://tools.ietf.org/html/rfc4287#page-14. I read type="text" to map to text/plain. Other text/* media types can be specified. See clause #5. 5. If the value of "type" begins with "text/" (case insensitive), the content of atom:content MUST NOT contain child elements. -Al
Florent wrote: Hm you're right, AtomPub doesn't allow sending text/* in base64. I hadn't realized its model was so restrictive. But anyway if you pick a file from the filesystem, how do you know that it's text, and that its media type is text/something? If you have out-of-band information that gives a media type of text/ something, but without an encoding, then something is missing for it to be interpreted correctly anyway by a processor that cares about media type. But I agree that legacy systems may have such partial information. I'd say in that case just guess the encoding if you can, or otherwise pretend it's ISO-8859-1 which will allow all bytes to be transmitted and stored back in the same way. Florent On Jul 24, 2009, at 1:01 PM, Florian Müller wrote: > If I treat it as a binary then I have to set a content type > different from text/* (see AtomPub spec 4.1.3.3). The only possible > content type would be application/octet-stream. That would be a loss > of information. > Through the SOAP interface I can upload the content AND set a text/* > content type. > > Florian > > > -----Original Message----- > From: Florent Guillaume [mailto:fg@nuxeo.com] > Sent: Friday, July 24, 2009 12:18 PM > To: Florian Müller > Cc: cmis@lists.oasis-open.org > Subject: Re: [cmis] Text encoding in AtomPub > > Basically if you don't know the encoding, then it's not text, it's a > binary. > > Florent > > On Jul 24, 2009, at 10:52 AM, fmueller@opentext.com wrote: > >> Hi, >> >> Here is a question to all the CMIS AtomPub client developers out >> there: >> >> I got stuck with document creation. In order to comply with AtomPub, >> text files must not be base64 encoded but enclosed in the <content> >> tag as plain text. This text must use the same encoding as the Atom >> XML around it. >> If I pick up a text file from the file system I don't know the >> encoding of this file and therefore I can't re-encode the text >> correctly. If the original encoding of the text file and the >> encoding of the Atom XML don't match by coincidence the document >> content in the repository will be different from the original >> content. That is, I can't rely on this method. Since creating >> documents in two steps (entry first, then adding content) is not >> supported by all repositories this is not viable option either. >> >> Do I make an error in reasoning or do we have a real issue here? >> >> >> Thanks, >> >> Florian >
-- Florent Guillaume, Head of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM)
|