Cart
[Home] [By Thread] [By Date] [Recent Entries]
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. ;-) len From: Karl Waclawek [mailto:karl@w...] > 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. Karl ----------------------------------------------------------------- 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>
|
