[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: CDATA

• To: "Bullard, Claude L \(Len\)" <clbullar@i...>,<xml-dev@l...>
• Subject: Re: CDATA
• From: "Karl Waclawek" <karl@w...>
• Date: Wed, 2 Apr 2003 11:39:24 -0500
• References: <15725CF6AFE2F34DB8A5B4770B7334EE022DC083@h...>

> That's what Grimaldi suggested and then Rick countered 
> with the problems of transcoders, etc.  

I now read Ricks' article, and yes, the transcoding issue is a good
argument. However, it really depends on the parser implementation.

As far as I can tell, Expat integrates the transcoder with
the tokenizer and processes the input character by character.
Just like it would be necessary: It could report the START_NDATA_SECTION
token *before* the next, potentially invalid, byte of input is encoded.

> If one wants to do more (eg, stuffing inlined 
> binaries), the fragility of XML starts to out 
> One has to create a different system.
> Just don't call it an XML processor.

What about an XML pre-processor? Which means: the input is not XML,
but the pre-processor removes the binaries, inserts some tags with
special meaning in their place and its output is valid XML.

But that could be seen as just separating two intermixed data streams
that are somehow linked through some synchronization protocol - outside
of the realm of XML. Generally I like keeping esparate things separate,
good advice for any programmer.


Karl

• References:
  • RE: CDATA
    • From: "Bullard, Claude L (Len)" <clbullar@i...>

• Prev by Date: NDATA section (was: RE: CDATA)
• Next by Date: Re: E4X
• Previous by thread: RE: CDATA
• Next by thread: Re: CDATA
• Index(es):
  • Date
  • Thread