W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2000

RE: [DR008] - passing arbitrary content

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Wed, 6 Dec 2000 09:33:56 -0800
Message-ID: <001d01c05faa$b878d6e0$308f3b9d@redmond.corp.microsoft.com>
To: <dick@8760.com>, "Andrew Layman" <andrewl@microsoft.com>, <xml-dist-app@w3.org>
> Thanks for clarifying the point regarding hex/base64, Base64
> is certainly
> more appropriate in this context.

Yes, my mistake - it was a typo.

> I want to explore one of your comments more thoroughly:
> > Base64 is a supported type within XML Schemas.  The main point is
> > that it is
> > easily possible to carry small amounts of binary data inline in XML.
>
> Does this mean there is an "upper limit" for the amount of
> binary data that
> XP should be
> expected to carry? For example, one of our clients, an
> electric company,
> regularly provides
> a "profile" of its entire customer base, totaling 150 MB, to marketing
> companies that are interested in this
> information. Would you consider a 150 MB binary payload
> beyond XP's intended
> use?

I don't think this is an XP question per se but an XML schema question.
It is possible to compose a derived type with a maxLength (in octets)
constraining facet but there does not seem to be a default maxLength.

Btw, this is of course not the only way you can carry data in XP - you
can refer to it using links, see for example [2].

I think more this is a pragmatic question of how much data you want to
carry this way as it has to be encoded. Using MIME multipart with 150M
as one entity body is not really practical either as the recipient could
have to read every single byte to find the delimiter as there is no
mandatory content-length header field defined for MIME (and it doesn't
work the same way as in HTTP), see [1]. Not to mention that it would
exceed many mailbox sizes.

Using HTTP without MIME multipart would seem to be a better way which
could be indicated by having the link be a http: URI. That way, you can
also take advantage of caches etc.

> > Regarding referencing data using a URI, the URI does not
> need to reference
> > remote data.  It can reference another part within a
> > multipart-MIME package.
> > See
> >
>
> I agree, this is the same technique used by ebXML. ebXML
> manifest entries
> "reference" local (in the same MIME package) MIME body parts via URI's
> containing MIME Content-ID's. Perhaps it would be
> worthwhile to define the requirements of local and remote
> references so that
> both are covered in XP's requirements doc.

As the requirement is that they are URIs both cases are covered by
default as URIs don't distinguish between "remote" or "local" - they are
all just identifiers.

Henrik

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
[2]
http://www.hpl.hp.com/personal/John_Barton/HTTP-A/SOAPAttachments16OCT00.htm
Received on Wednesday, 6 December 2000 12:34:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:57 GMT