[
Lists Home |
Date Index |
Thread Index
]
This was basically the gist of my suggestion last week; however, I was
convinced of its unsuitability in fairly short order. The encoding
problem seems to be the kind of issue that might be able to be worked
around, but the result would likely be a messy, unsatisfactory "bodge"
(that is the British term, yes?).
Plus, it seems to me that the only problem with binary encoding is if
you want to embed large chunks. For short items, like encoded
signatures for security purposes, the overhead doesn't matter that much.
And for longer items, it seems to me that embedding, for example, video
(!) in XML begs the real question, which is how to manage heterogeneous,
distributed content, not how to force it all to fit into an XML doc.
Linda
-----Original Message-----
From: Karl Waclawek [mailto:karl@waclawek.net]
Sent: Wednesday, April 02, 2003 9:02 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] CDATA
> 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>
|
