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] Some comments on the 1.1 draft

[ Lists Home | Date Index | Thread Index ]

Sorry but my use case is not serializing arbitrary binary data, but
arbitrary TEXT data according to the originating type system (such as a
database or a C#, C++, Java etc based webservice). Unfortunately, such
TEXT properties may contain control characters, since the originating
type system does not preclude them. Requiring people to base 64 encode
TEXT just to deal with the 0.1% of cases where control characters may
appear seems to be problematic.

Base 64 encoding of binary data has still its place to guarantee
semantic preservation of the binary format across different binary base
systems (such as LE and BE and EBCDIC vs Unicode). But it is overkill in
the above scenarios.

And pointing out ASN.1, JNI, TDS and other binary formats is missing the
point that the world is currently moving towards using XML for
serialization in many contexts. And purists may scream about this, but
SOAP/XML Protocol, WebDAV etc are not going away because of that and
they will continue to use XML...

Best regards

PS: Gavin, please call me Michael (or spell my last name correctly, it
is short enough after all).

> -----Original Message-----
> From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
> Sent: Wednesday, December 19, 2001 8:59 AM
> To: Alan Kent; Rick Jelliffe
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Some comments on the 1.1 draft
> On Wednesday 19 December 2001 05:24 am, Alan Kent wrote:
> > If I have understood your desire, I guess we differ here. I would
> > rather see XML (that claims to support Unicode) support all of
> > I *personally* don't feel that prohibiting valid Unicode characters
> > from appearing in documents is worth the benefit of protecting
> > against feeding in data in the wrong encoding.
> Control characters are suspect at best though.
> What I don't think people understand is that representing binary data
> *characters* for the sake of convenience will only open up the system
> abuse on one hand, and make *both* text *and* binary transfer
> In the example Mr. Rhys gave of serializing arbitrary binary data into
> document, the only way that the system can reliably *decode* the data,
> to
> work by converting characters into bytes, and then calling the
> deserialization tools on that. Possible, yes, but guess what? YOU
> EXACTLY THE SAME THING TODAY if you used BASE64 encoding.
> If you don't do this,  your binary data *cannot* be reliably
> especially in the face of transcoding.
> -----------------------------------------------------------------
> 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