[
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. ;-)
len
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.
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>
|
