From: Farrell, Lee (Lee.Farrell@cda.canon.com)
Date: Wed Jan 31 2007 - 15:53:09 EST
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@comcast.net [mailto:wamwagner@comcast.net]
Sent: Wednesday, January 31, 2007 11:49 AM
To: Farrell, Lee; wims@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@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@sharplabs.com]
Sent: Wednesday, January 31, 2007 8:39 AM
To: 'wamwagner@comcast.net'; Farrell, Lee; wims@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@sharplabs.com
-----Original Message-----
From: owner-wims@pwg.org [mailto:owner-wims@pwg.org]On Behalf Of
wamwagner@comcast.net
Sent: Tuesday, January 30, 2007 10:31 PM
To: Farrell, Lee; wims@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@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@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
This archive was generated by hypermail 2.1.4 : Wed Jan 31 2007 - 15:53:21 EST