Re: Fwd: Atom format interpretation question

2007-01-07 Thread Sam Ruby


James M Snell wrote:

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


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

I don't see the ambiguity.


- James

James Holderness wrote:

Sam Ruby wrote:

James M Snell wrote:

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.

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

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








Re: Fwd: Atom format interpretation question

2007-01-07 Thread James M Snell

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:
> 
> Sam Ruby wrote:
>> James M Snell wrote:
>>> 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.
>>
>> s/escape/Base64/
>> s/like text/as binary/
> 
> 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
> 
> 



Re: Fwd: Atom format interpretation question

2007-01-07 Thread James Holderness


Sam Ruby wrote:

James M Snell wrote:

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.


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


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



Re: Fwd: Atom format interpretation question

2007-01-07 Thread Sam Ruby


James M Snell wrote:

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.


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

- Sam Ruby



Re: Fwd: Atom format interpretation question

2007-01-05 Thread Asbjørn Ulsberg


On Fri, 05 Jan 2007 05:56:29 +0100, James M Snell <[EMAIL PROTECTED]>  
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.


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



Re: Fwd: Atom format interpretation question

2007-01-05 Thread Asbjørn Ulsberg


On Fri, 05 Jan 2007 05:22:30 +0100, Tim Bray <[EMAIL PROTECTED]> wrote:


John Cowan wrote:

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.


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»



Re: Fwd: Atom format interpretation question

2007-01-05 Thread Joe Gregorio


On 1/5/07, Bob Wyman <[EMAIL PROTECTED]> wrote:

On 1/4/07, James M Snell <[EMAIL PROTECTED]> 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?


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 Gregoriohttp://bitworking.org



Re: Fwd: Atom format interpretation question

2007-01-05 Thread Bjoern Hoehrmann

* Bob Wyman wrote:
>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?

RFC 3023 and RFC 4288.
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · 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/ 



Re: Fwd: Atom format interpretation question

2007-01-05 Thread Bob Wyman

On 1/4/07, James M Snell <[EMAIL PROTECTED]> 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


Re: Fwd: Atom format interpretation question

2007-01-04 Thread James M Snell

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:
> 
> Begin forwarded message:
> 
>> From: John Cowan <[EMAIL PROTECTED]>
>> Date: January 4, 2007 8:08:06 AM PST (CA)
>> To: [EMAIL PROTECTED]
>> 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 PROTECTED]  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)
> 
> 
> 



Fwd: Atom format interpretation question

2007-01-04 Thread Tim Bray


Begin forwarded message:


From: John Cowan <[EMAIL PROTECTED]>
Date: January 4, 2007 8:08:06 AM PST (CA)
To: [EMAIL PROTECTED]
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 PROTECTED]  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)