Bill/Ira,
I have no problem with preserving legacy usage. I think that's a good
idea. My only issue is that that usage doesn't seem to be
defined/explained in this specification.
I think Bill's background explanation is helpful. My only thought is
that if it is necessary to clarify the intent behind "media accounting
key", shouldn't the explanation (in some form) be included in the
document?
For instance, is the structure given in the example
("moid=xxxx;mtyp=yyy") a requirement -- or is it truly free form? Must
the value be machine readable, or not? Are there two components
necessary in the value (e.g., moid *and* mtyp?) -- or is only one
adequate (e.g., "USAB700045")? Is it completely inplementation
dependent? I couldn't tell these things from the existing text.
I think I understand Bill's suggestion for a definition:
"A additional non-localizable element ensuring locally unique
identification of a specific media, for use when MediaUsed.MediaSizeName
by itself is not unique."
But (as I read it), these words do not imply anything about "machine
readable" -- or that it must not be localizable, or whether to supply
two or one component(s) of information. If none of that is necesary or
appropriate for the definition because it is truly free form text, then
it's fine with me. If however, as the example seems to imply, some of
these characteristics are critical, then I think we should be explicit
about it. Where else would one go to find this stuff out?
NOTE: As written, the proposed definition above doesn't really seem to
be all that different from the definition used for MediaUsed.MediaInfo.
[The reason I'm not offering an alternate definition is because I'm not
yet sure of all the intended syntax requirements.]
lee
________________________________
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Wednesday, January 31, 2007 8:39 AM
To: 'wamwagner at comcast.net'; Farrell, Lee; wims at pwg.org
Subject: RE: WIMS> Revision to Counter Spec
Hi Lee,
The term 'media accounting key' was used in Xerox and Sharp projects
I've been involved in before - I was attempting to preserve legacy usage
in the name. As Bill noted, the 'key' part is a hint that this is
machine-
readable and MUST NOT be re-localized when the print service or
print device locale is changed.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - FSG Open Printing Steering Committee
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com
-----Original Message-----
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On Behalf Of
wamwagner at comcast.net
Sent: Tuesday, January 30, 2007 10:31 PM
To: Farrell, Lee; wims at pwg.org
Subject: RE: WIMS> Revision to Counter Spec
Lee,
Thank you for your comments. I obviously should have provided more
background information.
Ira will probably provide some additional details, but perhaps the
following will help.
Among the various items kept track of by the elements defined in the
counter spec are the media used and how they are used (impressed with
monochrome image, full color image, etc.). To do this, there must be a
way to uniquely define a specific type of media. The Candidate Standard
5106.1, as approved, says in paragraph 5.3:
"The elements MediaUsed.MediaSizeName and MediaUsed.MediaInfo are used
to uniquely identify a type of media. "
The idea was that if all media in a given system, or a given
environment, were distinguishable by size alone, then the different
media are uniquely differentated by MediaUsed.MediaSizeName. However, if
there were different media types of the same size, then some additional
element must be used to differentiate between them. MediaUsed.MediaInfo
was available, and was sufficiently free form so that any set of
distinguishing characteristics could be used (weight, color, letterhead
imprint, etc). Problem that Stuart identified with MediaUsed.MediaInfo
is that it is intended for human consumption and as such is localizable.
This makes it difficult to use reliably as a machine readable
identifier.
So the idea was to add another element that was not localizable and not
specifically intended for human consumption. Therefore Ira came up with
the new element "MediaUsed.MediaAccountingKey". The name is just a
cipher; but Ira felt that there was some precedent in using "key" in
this context. The intent is to provide uniqueness within the environment
that is being monitored, not necessarily universal uniqueness.
Therefore, whatever the set of values is used, its meaning must be well
known by the the machines and applications using it, but need not (and
could not) differentiate all of the possible distinguishing features in
media. I think Ira does have some suggestions for the format of this
element value that he may describe in the MIB. But these can only be
suggestions. Being an old hardware person, I would just as soon use a
bit map (in which case the type should be an octet string)... but that
is obsolete thi! nking.< /FONT>
Now, with that background, how could be better phrase the description?
Is
"A additional non-localizable element ensuring locally unique
identification of a specific media, for use when MediaUsed.MediaSizeName
by itself is not unique."
better?
We could add:
"This element MUST clearly distinguish different instances of the same
media size (for example, by including specific media color, weight,
etc.) "
and take the corresponding sentence out of the MediaUsed.MediaInfo
description, which currently reads:
The description of this specific media. (e.g. Light blue deckle-edge
letter stock) This description MUST clearly distinguish different
instances of the same media size (for example, by including specific
media color, weight, etc.)
Please let me know if this clears up the question.
Thanks.
Bill Wagner
-------------- Original message --------------
From: "Farrell, Lee" <Lee.Farrell at cda.canon.com>
I just read the modifications to the document.
I'm a bit concerned that the definition of
MediaUsed.MediaAccountingKey ("The locally unique accounting key for
this specific media, for use when MediaUsed.MediaSizeName is not
unique.") might not be sufficient to convey your requirement for this
item. What is meant by an "accounting key"? Is that a generally
well-defined term? I couldn't find the definition anywhere in this
document.
Based on the example provided for its use, there seems to be an
implicit intent to have the value provide *two* critical pieces of
information -- presumably in some human readable form that convey an
association of two distinct things. In my reading, "The locally unique
accounting key for this specific media, for use when
MediaUsed.MediaSizeName is not unique." doesn't suggest a need to
identify two "things" -- or what those things are.
But maybe everyone else understands the meaning of "accounting
key" more clearly than I do?
lee
________________________________
Sent: Monday, January 29, 2007 10:38 PM
To: 'wims at pwg.org'
Subject: WIMS> Revision to Counter Spec
Jerry provided the MS Word version of the approved counter
spec, and I made the changes that Ira and Pete had requested (taking a
few liberties with the wording). A marked up doc file is at
ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimscount10-20070201.doc
<ftp://ftp.pwg.org/pub/pwg/wims/wd/wd-wimscount10-20070201.doc>
(sorry, I am back in Boulder and do not have my PDF generator)
The changes are to document page 8 (Datastream change) and to
document pages 27 and 28 (MediaUsed.MediaAccountingKey addition)
This working draft is submitted for working group review, with
the objective of be able to submit it for a PWG review period including
the February face to face. Please review and submit objections before
the next WIMS/CIM meeting on 8 Feb.
Thank you.
Bill Wagner
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.17/661 - Release Date:
1/30/2007 11:30 PM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070131/46cec23d/attachment.html