-----Original Message-----
>From: BIGELOW,JIM (HP-Boise,ex1)
>Sent: Monday, January 27, 2003 3:55 PM
>To: WISSENBACH,DAVID (HP-Boise,ex1); 'xp@pwg.org'
>Subject: RE: Specifying the Persistence of Appmuxed Reference Objects
>What if the contentID were unique for each image but the content-Location
>identical for each identical image. For example, in the case of a series
of
>paragraphs that start with the same image, an information icon, the
document
>would look like the following:
This might solve my problem--not wanting to modify the root document for a
variety of reasons. I'd change this proposal slightly to not specify a
Content-ID in the mime header for each image if the references were relative
URLs, indicating reference by Content-Location.
Of course, we would continue to support the straightforward method of
modifying the original document to use a unique Content-ID for each instance
of the repeated image in the stream.
><p class="info"><img src="info_icon.jpg" height="10" width="10">
>Informational message: daba daba do...
></p>
><p class="info"><img src="info_icon.jpg" height="10" width="10"> Windows
Haiku: Serious error. All shortcuts have disappeared.
>Screen. Mind. Both are blank.
></p>
>Then the multiplexed document would interleave the same image twice,
>each with different contentID's but identical, "info_icon.jpg",
content-Locations.
>For example the multiplexed document could look like the following:
I would have the multiplexer leave the Content-ID out. (Think of the missing
Content-ID as a promise by the application-multiplexed document not to refer
to this image in the compound document by content-ID.)
I've modified the example accordingly.
Content-Type: application/vnd.pwg-multiplexed;
type=application/vnd.pwg-xhtml-print+xml
CHK 1 428 MORE
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Location: infomsg.html
Content-Disposition: inline
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://ww.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>info</title>
</head>
<p class="info"><img src="info_icon.jpg" height="10" width="10">
Informational message: daba daba do... </p>
CHK 2 512 LAST
Content-Location: info_icon.jpg
Content-Type: image/jpeg
... Header bytes of first instance of info_icon.jpg ...
CHK 1 253 MORE
<p class="info"><img src="info_icon.jpg" height="10" width="10"> Windows
Haiku: Serious error. All shortcuts have disappeared. Screen. Mind. Both are
blank. </p>
CHK 3 1024 LAST
Content-Location: info_icon.jpg
Content-Type: image/jpeg
... Header bytes of second instance of info_icon.jpg ...
CHK 1 113 LAST
Content-Type: application/vnd.pwg-xhtml-print+xml
Content-Location: infomsg.html
Content-Disposition: inline
<body>
</body>
</html>
CHK 0 0 LAST
>This method would allow the printer to only store the single image since
the names are the same.
What I would do in the MIME demultiplexer when the clone of the image
arrives (and I know that it is a clone because the Content-Location is the
same) is determine whether the XHTML-Print processor had consumed and
discarded any data from the first instance, depending on the implementation
of the XHTML-Print processor. If the XHTML-Print processor has consumed some
of the data in the first image, then the MIME demultiplexer would have to
create a new content-handler and storage for the clone. If the XHTML-Print
processor has not consumed any data in the first image, then the MIME
demultiplexer would increment a reference count in the store of the first
image and discard all further data with channel 3 in the chunk header.
In effect, we are no longer conforming to one constraint of RFC2557, that
unique Content-Locations be assigned to each part of the message. But this
is a case not addressed by RFC2557, because this part of the document is an
exact copy, or clone, of the first.
>Based on this approached I suggest the following, amended paragraph be
added to section B.2:
>Producers and consumers of Application/Vnd.pwg-multiplexed
>entities, as defined in [MIMEMPX], should consider each
>image as having one and only one reference. The producer
>should not make assumptions about the buffering abilities
>of the consumer of an Application/Vnd.pwg-multiplexed
>entity and include a copy of an image for each reference
>to it. Each chunk containing an image should have a unique
>ContentID and a Content-Location whose value is the name
>of the image referenced in the src attribute of the img
>element or the href attribute of the object element.
>Consumers may release the resources associated with
>an image when the reference to it is satisfied, and are
>free to optimize references to identical images in an
>implementation dependent manner.
I'd change the paragraph in B.2 to the following:
Producers and consumers of Application/Vnd.pwg-multiplexed
entities, as defined in [MIMEMPX], should consider each component image
message of the compound document as having one and only one reference. The
producer of the compound document must assume that the consumer of
the Application/Vnd.pwg-multiplexed entity has limited memory and
therefore include a unique image message for each image reference
found in the root document. If a ContentID is present in the header of
an image message, that ContentID must be unique. If a Content-Location
is present in the header of an image message, that Content-Location
is required to be unique except for the special case where a repeated
reference
to the same image URL causes several messages containing of the exact same
image data to be
present in the compount document. Consumers may release the message data
associated
with an image reference as the image is rendered, because the Consumer can
be
confident that another reference to the same image will be accompanied by
another message containing an copy of that same image data. Consumers
may also substitute image data for a message with a given Content-Location
header value with
image data from other messages with the same Content-Location header value
because
Consumers can be confident that messages with identical Content-Location
values
do in fact contain identical data.
I suggest a further clarification by adding a following paragraph.
URL references in the the root document of the multiplexed document must be
matched to
Content-Location and/or Content-ID fields of the referenced message object
according
to the rules given by RFC2557. An exception to the rules given by RFC2557
occurs when a reference is made to a message object named with a
Content-Location. In
that special case, multiple instances of that message are required in the
compound document.
This archive was generated by hypermail 2b29 : Tue Jan 28 2003 - 12:27:17 EST