Re(3) Regarding the Thursday ebXML Conf Call

["Dale Moberg" <Dale_Moberg@stercomm.com>]

Nikola Stojanovic <nstojano@cjds.com> on 03/03/2000 12:16:06 AM
                                                                                
                                                                                
                                                                                


                                                           
                                                           
                                                           
 To:   David RR Webber <Gnosis_@compuserve.com>, Duane     
       Nickull <duane@xmlglobal.com>                       
                                                           
 cc:   "ebXML Transport (E-mail)"                          
       <ebXML-Transport@lists.oasis-open.org>,             
       ebXML-Architecture@lists.oasis-open.org(bcc: Dale   
       Moberg/Sterling Commerce)                           
                                                           
                                                           
                                                           
                                                           
                                                           








<David>
> First of all,  you cannot declare binary data as CDATA.<
>
> >>>>>>>>>>
> Technically the way to do this is using UUENCODING  - but that makes for a
> massive file, but doable.
</David>

<http://www.ucc.ie/xml/>
(It would, however, be possible to include a text-encoded transformation of
a binary file as a CDATA marked section, using something like UUencode with
the markup characters ] and > removed from the map so that they could not
occur and be misinterpreted.)
</http://www.ucc.ie/xml/>

<Dale>

I think that a useful metric would be to take the
 various requirements (like embed JPEG)
and then count up how many modifications and
adaptations are needed to implement
the functionality in the xml- purist approach and
then contrast them with what is needed with
the diversity-tolerant approaches. There is no
doubt that with sufficient added complexity
in either the lexical tokenizer, the parser, the xml
interpreter, and with sufficient auxiliary
extensions using Xlink or XML Fragment and so on
that a pure package in XML could be
assembled.

But, it is a little disappointing to get HTTP,
with its ability to transport binary data,
and then build back in
base64 encodings because we want to
stash JPEGS in an XML message body.

Doesn't anybody
think that this is an early warning sign that
everything is looking like a nail because we are
only allowed to use a hammer?

</Dale>