OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] CDATA

[ Lists Home | Date Index | Thread Index ]

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

I've seen systems that make it work, but it does get 
into areas where SGML systems became complex. One 
of those systems, Interleaf, was a WYSIWYG editor 
and allowed inlined bitmaps.  You are right about 
regular text editors.

Interesting.  If one wants to do less with XML (see 
SOAP and XMPP protocol subset debates), that is OK.
One has to create a different system.
Just don't call it an XML processor.

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.

Hmm. XML really is an *offramp* to SGML. ;-)


From: Karl Waclawek [mailto:karl@waclawek.net]

> Maybe the requirement is to support NDATA.  I get a lot 
> of inquiries about stuffing jpegs, etc, inline.  When 
> I show them the limited means, I get frowns.  Perhaps 
> it is time to revisit that permathread.

One could prefix such an NDATA section with a length tag,
allowing the parser to simply ignore the next "length" bytes.
That essentially takes the NDATA section out of XML land.
Only drawback: regular text editors have problems with binary data.


The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS