RE: Possibility of an XML Document Type

<delurk>
Representing the user community for this spec, I'd like to offer this
perspective:  it's an important design point for us to be able to carry
payloads in formats other than XML (the standard example being COBOL
copybooks -- yes we still have a lot of mainframe processing).  From our
perspective, then, it would be desirable to have a uniform way of handling
payloads, whether they are XML documents or COBOL copybooks.
</delurk>

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Wednesday, October 10, 2001 6:51 AM
To: Jean-Jacques Moreau
Cc: Noah_Mendelsohn@lotus.com; xml-dist-app@w3.org
Subject: Re: Possibility of an XML Document Type


I really don't understand why "nesting" XML documents within
an XML document using some hokey encoding is in any way
more efficient, elegant or otherwise more useful than MIME
and simple links (href, xlink, etc.) and a URIResolver that
is MIME aware.

To be certain, it adds some overhead (mime libraries) for
small devices, but it would seem to me that there is nearly
as much overhead in including base64 libraries and extra
processing (and memory utilization!) to en/decode the
embedded bits.

The MIME "baggage" can be profiled for smaller devices
if that is necessary. For that matter, you can simply not
support complex message types requiring embedded XML
documents on small devices.

Any interesting use of SOAP is likely going to involve
attachments and SwA seems to have quite a bit of support
in the implementation space (apache soap, apache axis, jaxm)
I'm sure there are others.

I just don't get this argument at all. Ignoring the problem won't
make it go away. SwA is useful in a number of contexts, why not
accept this fact and move forward? We don't even have to be
exclusive to MIME.

Cheers,

Chris

Jean-Jacques Moreau wrote:

> This would be my perferred option as well. Short term, this may be
unsuited to
> large documents or performance critical situations, as you point out
(although
> there are work arounds), but medium term this will provide the easiest
> transition to "nested" XML. I don't think we should require the extra S+A
> bagage.
> 
> Jean-Jacques.
> 
> Noah_Mendelsohn@lotus.com wrote:
> 
> 
>>[...] I'm [...] tempted to push for the datatype as a solution that works
>>uniformly over any transport, and indeed extends beyond SOAP to other
>>applications requiring XML documents in XML.  No doubt, it is unsuited to
>>large documents or the most performance critical situations.
>>
>

Received on Wednesday, 10 October 2001 10:43:42 UTC