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
HYPERLINK
"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/fc8782d9/attachment.html