[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [syndication] Re: Digest Number 130



On Tue, 26 Sep 2000, Rick Winfield wrote:

> I chose to use the CDATA method at work.  We have a partner (one of 
> the major portals so they actually have programming resources) that 
> wanted XHTML, but since our documents are originally authored in HTML 
> (as would be the "normal" case in my opinion) this wasn't possible.
> 
> Do you think it would be that hard to get people to use CDATA?

CDATA sections are easy to do/enforce in software, but not for
hand-authored content.  However, if you're really requiring that
the data be well-formed XML, then this is not an issue. The concern
with RSS (or, better put, the RSS 0.91 model) is that the data is
often hand coded, and often is not actually well-formed XML. HOwever,
most dedicated RSS processors are either lenient XML processors (they
allow for and/or correct simple XML errors), or they simple perl scripts
that use regex expressions to match for element content. Such tools
probalby don't support richer XML constructs like CDATA.

Ian
 
> --- In syndication@egroups.com, Ian Graham <ian.graham@u...> wrote:
> > 
> > On Mon, 25 Sep 2000, Aaron Swartz wrote:
> > 
> > > Ian Graham <ian.graham@u...> wrote:
> > > 
> > > > (a) put the HTML inside a CDATA section (to escape it, so to 
> speak),
> > > > or (b) use things like base64 encoding (and/or compression) to 
> package
> > > > the data up.  Both are, unfortunately, non-simple.....
> > > 
> > > There's also the option of using entity encoding (like 
> &lt;br&gt;) -- this
> > > is supported by almost all parsers and most HTML/XML-enabled 
> scripting
> > > environments. Of course, it's much harder than a CDATA section to 
> read by
> > > hand (which is the purpose of XML to begin with).
> > > 
> > > What's so non-simple about a CDATA section, though? It seems to 
> me rather
> > > easy to output the opening and closing CDATA tags. A problem may 
> be that it
> > > isn't properly supported by some parsers, but this is a fault of 
> the parser
> > > (since it is in the spec), and shouldn't be too difficult to 
> remedy.
> > 
> > I meant non-simple in the 'I can author this by hand' sense. As a 
> pure
> > coding issue it is by far the easiest choice -- the only thing you 
> need to
> > escape would be any bare ]]>'s inside the HTML (or, equally well, 
> XML)  
> > markup. 
> > 
> > I'll have more up on the Web site on this later this week :-)
> > 
> > Ian
> 
> 
> 
> 
>