Hi Bill,
I like your rewording and I like including Lee's examples (to clarify
that a structured value is an implementation choice, not required).
Note - I plan to propose the structured value be RECOMMENDED
in the revised Counter MIB, because it has a well-defined format
that can be machine-detected and interoperably processed across
vendors and different client software tools. Vendors can even use
safe vendor custom tags like 'chp-tooth=fine', constructed 'c' +
'vendor' + '-' + 'keyword(s)'.
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: Thursday, February 01, 2007 12:01 AM
To: Farrell, Lee; wims at pwg.org
Subject: RE: WIMS> Revision to Counter Spec
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
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
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
2:28 PM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070202/d3f85c9a/attachment.html