Subject: Re: atom:name ... text or html?

From: Antone Roundy <[email-masked]>
Date: Thu, 23 Mar 2006 10:43:48 -0700

On Mar 23, 2006, at 9:48 AM, James Holderness wrote:
> Hahaha! It's RSS all over again. In the words of Mark Pilgrim:  
> "Here's something that might be HTML. Or maybe not. I can't tell  
> you, and you can't guess." :-)
>
> Seriously though, the atom:name element is described as "a human- 
> readable name", so unless your name really is "Betrand  
> Caf&eacture;" that can't be right. If RFC4287 had intended to allow  
> markup in the element it would have used atomTextConstruct.

I agree with James here--if we had intended for the name to be able  
to include markup, we should have used the construct we created to  
allow that.  This from RFC 4287 (section 3.2):

    element atom:name { text }

would have been this:

    element atom:name { atomTextConstruct }

if we had intended for it to be able to contain anything but literal  
text after XML un-escaping, right?

On Mar 23, 2006, at 9:57 AM, Eric Scheid wrote:
> It's true that XML has only a half dozen or so entities defined,  
> meaning
> most interesting entities from html can't exist in XML ... unless  
> maybe they
> are wrapped like in CDATA block like above?
If they're wrapped in a CDATA block, then they don't trigger an XML  
parsing error, but wrapping something in CDATA isn't a license to  
enter data in a format other than what the RFC allows.

> I'm getting the data by scraping an html page, so I'm expecting it  
> to be
> acceptable html code, including html entities.
You, the producer, are getting the data from an HTML page, so you  
should certainly be prepared to handle HTML entities in it. But you  
the Atom publisher are responsible for making sure that you've made  
any changes to the data that are necessary for it to be proper Atom  
before you publish it. The consumer of the Atom feed doesn't know  
where you got the data, and thus can't be expected to decide how to  
process it based on where you got it.