Ira (or anyone else),
Any objection to the rewording and the inclusion of Lee's examples? If not, I will make the changes and repost.
Thanks.
Bill Wagner
-------------- Original message --------------
From: "Farrell, Lee" <Lee.Farrell at cda.canon.com>
Great, we're getting to the heart of my concern.
I like your definition (now even better) -- and I agree that the example provided (the "moid=xxxx;mtyp=yyy" thing) was what confused me. I read it as an implication of additional intent which was not clear (to me) by the definition or the data type.
With this clarification, it works for me.
As far as the suggested example, it would be fine to include Ira's current example -- but I think a contrasting alternative example would be good to underscore that there is no implied "two-component" aspect to the content.
E.g.
As examples, the following values could be all used:
"moid=1.3.18.0.4.3.1.50;mtyp=stationery"
"moid=1.3.18.0.4.3.1.50;mtyp=stationery-letterhead"
"USAB700045"
"vellum-with-holes"
Sorry for the distraction,
lee
From: wamwagner at comcast.net [mailto:wamwagner at comcast.net]
Sent: Wednesday, January 31, 2007 11:49 AM
To: Farrell, Lee; wims at pwg.org
Subject: RE: WIMS> Revision to Counter Spec
Lee,
Understood. When I actually made the change to the proposed text, it came out.
MediaUsed.MediaAccountingKey
A non-localizable element ensuring machine readable, locally unique identification of a specific media when MediaUsed.MediaSizeName by itself is not unique. This element MUST clearly distinguish different instances of the same media size (for example, by including specific media color, weight, etc.)
(string)0 to 255*
which may address some of the issues. Note that the introductory paragraph to the table also provides some information, although I realize that people may not generally look beyond the table entry.
The simple data type "string" suggests that there is no syntax requirement. And there is none, any more than there was for MediaUsed.MediaInfo. Perhaps Ira's example is misleading and we should use a simple example such as was used for MediaUsed.MediaInfo. Alternatively, it may be desirable to include how that example was constructed, although it must be stressed that that (or any other construction is not mandatory. Which do you think would be preferable?
Thanks.
Bill Wagner
-------------- Original message --------------
From: "Farrell, Lee" <Lee.Farrell at cda.canon.com>
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
(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/20070201/2fd324ea/attachment.html