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 thinking.
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
(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070131/e01b5ed5/attachment.html