RE: Two new drafts: Multipart/Interleaved and Application/BatchBe ep

Martin,

Could you give more detail about how you envision using external entities in
the context of the example I include below?

One of the problem's requirements is that a producer must be able to start
sending the data before it has produced all of the data.  So a solution
could not require that all entities be known and defined before transmission
begins.

A typical example is a document that consists of XHTML plus many images
where the XHTML is split into many chunks so that the images can be
interleaved among the XHTML chunks.  To provide something for our
conversation, I have taken the example from section 5.2 of the
multipart/interleaved draft and converted it to Multipart/related with
"<fragment .../>" elements which allow each XML fragment to reference the
next one. The question is whether there is an existing XML mechanism that
behaves like "fragment" element. Here is the example:

---------------------------
 
Content-Type: multipart/related; boundary="boundary-example";
              type="text/xhtml+xml"

--boundary-example
Content-Id: "49568.44343xxx@foo.com"
Content-Type: text/xhtml+xml;charset="us-ascii"
Content-Disposition: inline

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/TR/xhtml1">
	<body>
		<p>some text
			<img src="cid:49568.45876xxx@foo.com"/>
			<img src="cid:49568.46000xxx@foo.com"/>
			some more text after the images
		</p>
            <fragment ref="cid:49568.47456xxx@foo.com"/>
	</body>
</html>
--boundary-example
Content-ID: <49568.45876xxx @foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
--boundary-example
Content-ID: <49568.46000xxx@foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment

<binary data>
--boundary-example
Content-Id: "49568.47456xxx@foo.com"
Content-Type: text/xhtml+xml;charset="us-ascii"

		<p>some more text without images
		</p>
            <fragment ref="cid:49568.49333xxx@foo.com"/>
--boundary-example
Content-ID: <49568.47333xxx@foo.com>
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-Disposition: attachment

<binary data>
--boundary-example
Content-Id: "49568.49333xxx@foo.com"
Content-Type: text/xhtml+xml;charset="us-ascii"

		<p>some more text
			<img src="cid:49568.47333xxx@foo.com"/>
		</p>
 		<p>some final text
		</p>
--boundary-example--



> -----Original Message-----
> From: Martin Duerst [mailto:duerst@w3.org]
> Sent: Monday, April 16, 2001 8:32 PM
> To: Herriot, Robert; discuss@apps.ietf.org
> Subject: Re: Two new drafts: Multipart/Interleaved and
> Application/BatchBeep
> 
> 
> One possible solution to the problem described would be to take
> the XML document, cut out suitable pieces and put them into
> separate external entities, change the remainder of the XML document
> appropriately, and then use plain old Multipart/Related,
> with the core XML document first, and then the separated-out
> entities and the gifs interleaved as appropriate. For external
> entities, see http://www.w3.org/TR/REC-xml#sec-external-ent.
> 
> Regards,   Martin.
> 
> 
> At 12:36 01/04/16 -0700, Herriot, Robert wrote:
> >I recently published two drafts
> >
> >
> >http://www.ietf.org/internet-drafts/draft-herriot-multipart-i
nterleaved-00.t
> >xt
> >
> >http://www.ietf.org/internet-drafts/draft-herriot-application
> -batchbeep-00.t
> >xt
> >
> >(Note that the first draft is not available via the Internet 
> Drafts Search
> >engine, but is accessible via the URL supplied above).
> >The problem that motivates these two proposals is the case of an XML
> >document with attachments, such as gif images. Normally, a 
> Multipart/Related
> >representation would suffice. The first body part would be 
> the XML and the
> >remaining body parts would be gif images, each referenced 
> from the XML. But
> >when a memory constrained printer encounters a reference to 
> a gif image body
> >part in the XML, it might not have the space to hold the 
> remaining XML while
> >it scans ahead for the gif image. This problem suggests the 
> need to be able
> >to interleave chunks of XML and gif images. Each of the two 
> drafts provide a
> >solution for interleaving chunks.
> >Both drafts define new MIME types. The first draft defines
> >Multipart/Interleaved and Application/Chunk content types, 
> which extend
> >Multipart/Related for use with memory constrained devices. 
> The second draft
> >defines Application/BatchBeep content type, which defines a 
> MIME type whose
> >contents is the client-to-server portion of a BEEP session.  
> Although the
> >two drafts are based on two very different ideas, the 
> examples show that the
> >two solutions are nearly byte-for-byte identical. The 
> primary difference is
> >that the boundary string in the Multipart/Interleaved 
> solution is a trailer
> >and/or header in the Application/BatchBeep solution.
> >I would appreciate any comments on these drafts.
> >Bob Herriot
>

Received on Friday, 20 April 2001 09:37:35 UTC