PWG> Some comments on the XHTML-Print Draft D0.56

PWG> Some comments on the XHTML-Print Draft D0.56

PWG> Some comments on the XHTML-Print Draft D0.56

Hastings, Tom N hastings at
Wed Mar 7 02:23:27 EST 2001


Here are a few comments on Draft 0.56, in case the PWG decides to do some
work on it on Wednesday at its meeting  (I've also sent these comments to
the UPnP IMAGING DL since they are also working on it):

1. Will XHTML-Print Photo-Imaging be a separate MIME Media type, a parameter
of text/xhtml-print+xml, or neither (requiring the receiving device to
discover by reading the data?

2. It would be good to choose between "shall" and "must".  The current draft
uses these words interchangeably.  (I prefer MUST for English readers).

3. It would be good to add a Terminology section between sections 2 and 3.
The new section should define any terms that are used with special meaning
in the document.  The conformance language words "must" (or
"must")/"required", "should"/"recommended", and "may"/"optional" need to be
explained that they define conformance, as has been done in all IETF RFCs.
Either just list the terms in the new terminology section with a reference
to RFC 2119 as is done with RFCs, i.e.:

"RECOMMENDED", "MAY", and  "OPTIONAL" in this document are to be interpreted
as described in RFC 2119 [RFC2119].

or define these terms explicitly in the new Terminology section as:

a. MUST   This word, or the term "REQUIRED", mean that the
   definition is an absolute requirement of the specification.

b. MUST NOT   This phrase means that the definition is an absolute
   prohibition of the specification.

c. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

d. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

e. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

4. Also decide whether or not to use all caps for these conformance words.
The advantage of using all caps, as we did in IPP (and all IETF RFCs), is
that the conformance requirements are easier for the implementer to find.  I
suggest yes.

5. Page 7, Section 3.1 Tags Required by XHTML-Print, the first two sentences

The World Wide Web Consortium has defined a subset of XHTML 1.0 that is
targeted to small format devices such as PDAs and cellular telephones. The
definition of XHTML-Basic is therefore useful to be examined as a starting
point for the definition of XHTML-Print.

I assume that the subset of XHTML 1.0 being referred to in the first
sentence is XHTML-Basic.  So just replace "The definition of XHTML-Basic"
with "The subset is called XHTML-Basic and" in the second sentence, or some
such other way to connect the two sentences.

6. Page 9, section 4.1, Recommended attributes on the <img> and <object>
tags, has:

Printers are not
required to support:
  - Embedded Thumbnails
  - Rotation
  - Progressive rendering
within the JFIF files.

However, Appendix A talks about JFIF and EXIF files interchangeably, since a
Printer MUST support both.  So replace "JFIF" with "JFIF and EXIF (see
Appendix A)".

7. Page 14, section 4.6 Image Data, has:

See Appendix B for discussion of a method allowing both XHTML-Print and
associated image
data to be collected into a single file or data stream.

It is not clear whether or not Appendix B (Inline Image Data) is REQUIRED
for a Printer to support.  I suspect that it is, so:

a. Section 4.6: replace "a method" with "the REQUIRED method".

b. Section 5.1 XHTML Document Type Conformance, add the Image Data MAY be
Inline (see  Appendix B) or may be by reference (see ...).

c. Section 5.3.2 Printer Requirements, include that the Printer MUST support
Inline Image data as defined in Appendix B.

d. Appendix B, section 2.2 Intent, change "recommended" to "REQUIRED" in
"The intent of this appendix is to describe recommended behavior ..."

8. Page 17, section 5.1 XHTML Document Type Conformance, has:

<!DOCTYPE html PUBLIC "-//PWG//DTD XHTML-Print 1.0//EN"

Should there be a /pub/standards/ between and xhtml-print (as in
the agenda)?

Or should there be a /pub/pwg/standards/ between and

9. Page 24, section A.3.1 Handling of EXIF APP1 and APP2 Markers, has:

The following IFDs must be fully supported (i.e. they may not be ignored).

Change "may not" to "MUST NOT", since it is a conformance requirement that
the tags not be ignored, rather than an option to ignore.

10. Page 25, section B.2 Multipart MIME Related Method, has:

   Content-type: text/xhtml-print+xml/partial

Need to find a legitimate way to represent fragments of XML. Two levels of
sub-type is not permitted (i.e., can't have two "/" in the MIME Media type.
See other mail.

-----Original Message-----
From: don at [mailto:don at]
Sent: Tuesday, February 27, 2001 13:24
To: pwg-announce at
Cc: melinda_grant at; fujisawa.jun at;
peter.zehler at
Subject: PWG-ANNOUNCE> Charter for XHTML-Print Working Group

A working group to develop the XHTML-Print "datastream" is being proposed
the PWG.  I have included a pointer to a proposed charter which will be
discussed at the PWG Plenary in Tampa.

Comments should be sent to me or brought up at the Plenary in Tampa.  A
list for this project has not yet been set up yet.

* Don Wright                 don at *
* Chair, Printer Working Group               *
* Chair, IEEE MSC                            *
*                                            *
* Director, Strategic & Technical Alliances  *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 859-232-4808 (phone) 859-232-6740 (fax)    *

More information about the Pwg mailing list