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 09:54:24 UTC