Don,
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.:
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"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
are:
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"
"http://www.pwg.org/xhtml-print/xhtml-print10.dtd">
Should there be a /pub/standards/ between www.pwg.org and xhtml-print (as in
the agenda)?
Or should there be a /pub/pwg/standards/ between www.pwg.org and
xhtml-print?
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@lexmark.com [mailto:don@lexmark.com]
Sent: Tuesday, February 27, 2001 13:24
To: pwg-announce@pwg.org
Cc: melinda_grant@hp.com; fujisawa.jun@canon.co.jp;
peter.zehler@usa.xerox.com
Subject: PWG-ANNOUNCE> Charter for XHTML-Print Working Group
A working group to develop the XHTML-Print "datastream" is being proposed
for
the PWG. I have included a pointer to a proposed charter which will be
discussed at the PWG Plenary in Tampa.
ftp://ftp.pwg.org.pub/pwg/xhtml-print/charter/XHTML-Print-Charter-01.doc
Comments should be sent to me or brought up at the Plenary in Tampa. A
mailing
list for this project has not yet been set up yet.
**********************************************
* Don Wright don@lexmark.com *
* 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) *
**********************************************
This archive was generated by hypermail 2b29 : Wed Mar 07 2001 - 02:23:45 EST