Elliot,
Some interesting ideas here. Building on them, for the Job object that
contains Document objects, for which there might be several sets of Page
Overrides, we need to enhance your function:
value getActualValue(attr_name)
The context for the attribute has to be either passed in and/or returned,
such as for which document in a multi-document job the actual value applies
and for Page Overrides, for which page ranges of Page Overrides the actual
value applies.
So your notion of different methods being applied to a supplied attribute
seems appropriate for the PWG Semantic Model.
For an IPP binding of the PWG Semantic Model, adding the -actual suffix is
just the IPP binding of the PWG Semantic Model. Internally, the IPP
implementation could use the formulation that you propose.
As an XML approach, consider having an XML attribute indicate whether the
value is the requested, the actual, the default, the ready, or the
supported. For example, the "sides" attribute:
<sides>
two-sides-long-edge
</sides>
<sides-actual>
two-sides-long-edge
</sides-actual>
<sides-default>
two-sides-long-edge
</sides-default>
<sides-ready>
one-sided, two-sides-long-edge, two-sides-short-edge
</sides-ready>
<sides-supported>
one-sided, two-sides-long-edge, two-sides-short-edge
</sides-supported>
would become:
<sides>
two-sides-long-edge
</sides>
<sides context="actual">
two-sides-long-edge
</sides-actual>
<sides context="default">
two-sides-long-edge
</sides-default>
<sides context="ready">
one-sided, two-sides-long-edge, two-sides-short-edge
</sides-ready>
<sides context="supported">
one-sided, two-sides-long-edge, two-sides-short-edge
</sides-supported>
Tom
-----Original Message-----
From: ElliottBradshaw at oaktech.com [mailto:ElliottBradshaw at oaktech.com]
Sent: Friday, November 01, 2002 05:33
To: Dennis Carney
Cc: owner-sm at pwg.org; sm at pwg.org
Subject: Re: SM> ACT - Summary of today's discussion of the "-actual"
proposal
Maybe you've already discussed this and ruled it out, but have you played
with the idea that Every attribute has an actual value. In some cases
there would be no obvious reason why the printer would change it, but the
spec doesn't need to forbid it.
My brain keeps trying to think about actual as "a different kind of value
on an attribute" rather than "a different attribute". If we were doing
this from scratch (which I realize we are not!) it's almost as if each
object would have different methods:
-value getOriginalValue(attr_name)
-value getActualValue(attr_name)
-value getDefaultValue(attr_name)
-list getSupportedValues(attr_name)
-list getReadyValues(attr_name)
I hypothesize that a PWG newbie from e.g. the Java world would have the
same discussion with his/her brain...
Anyhow. Am I allowed to think of the -actual suffix as a modifier on a
basic attribute? Would it be legit to bind the SM to an API that works
that way?
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
"Dennis
Carney" To: sm at pwg.org
<dcarney at us.ib cc:
m.com> Subject: SM> ACT - Summary of
today's discussion
Sent by: of the "-actual" proposal
owner-sm at pwg.o
rg
10/31/2002
06:34 PM
Today in the Semantic Model teleconference, the 'IPP: "-actuals" attributes
extension' was discussed for the first time. Here is a summary of that
discussion, or at least a summary of the conclusions.
1) There seemed to be general agreement that this proposal was a step in
the right direction.
2) The discussion first veered into how the "-actual" attributes would fit
into the Semantic Model schemas. I would feel more comfortable with Peter
Zehler reporting the conclusion, but essentially I believe the conclusion
was that Peter's proposal for a ProcessingActual group was accepted.
Within the scope of SM, then, the "-actual" attributes do not need the "
-actual" suffix, since they are distinguished by XML schema structure from
the corresponding Job Processing attributes.
3) We discussed whether the "-actual" attributes should be Job Description
attributes or whether they should be part of a new attribute group,
something like the Job Actual attributes. It was decided they should be
Job Description attributes.
4) However, a new keyword for the "-actual" attributes needs to be added to
the possible keywords for the "requested-attributes" operation attribute
that is part of the Get-Jobs and Get-Jobs-Attributes operations. That is,
a client would be able to do a Get-Job-Attributes and ask for only the "
-actual" attributes by providing one single keyword, the new 'job-actual'
keyword.
5) A question was raised as to the intended use case this proposal was
written for. I said it was anybody trying to monitor jobs, whether they
were the job submitter or not. A question came up as to whether this could
be used for billing: "the job used 13 pages of letter paper, so charge them
$.26". I said this proposal was not detailed enough to handle complicated
billing issues (job printed some transparencies, some letterhead, some
staples, and so on), and it was mentioned I should add some comments to
this effect to the document.
6) We had a good discussion about whether the "-actual" attributes should
be multi-valued. For more details on this, I will point you to Tom
Hastings' email from a few hours ago, entitled 'SM> ACT - ISSUE:
multi-valued at job level vs. using "document-overrides-actual" and
"page-overrides-actual"'. The gist: some thought yes, some thought no, Tom
has three ISSUEs in his email.
7) There was a discussion of whether the operation attribute
"document-format" should have a corresponding "document-format-actual"
attribute. This would be an exception to the rule that "-actual"
attributes correspond only to Job Template attributes. It was decided that
there would NOT be a corresponding "-actual" attribute for this, but that
the Document Object spec would possibly address the flawed situation with
the "document-format" attribute and possibly create the equivalent of an
"actual" attribute for it.
8) It was pointed out that the "job-k-octets", "job-impressions", and
"job-media-sheets" attributes are already-existing "pseudo-actual"
attributes, in that these values can be provided by the client on job
creation, and can be overridden by the printer if it determines the
client-provided values are inaccurate. It was suggested to add a mention
of these three attributes in the "-actual" attributes document.
8a) There was some confusion (in my mind at least!) whether the document
should also mention "document-format" as an example of a "pseudo-actual"
attribute--it is confusing because at present, "document-format" *doesn't*
act this way, so it is hard to add a mention that it does. Maybe if the
Document Object spec makes it act this way, I can then add a mention of
that? Or maybe the request was that I mention "document-format" as an
example of an attribute that could/should be a "pseudo-actual", but isn't?
Or?
9) There was an high-level issue that arose frequently: whether the "
-actual"s concept should be extended to the Document Object, and if so,
how. I said I thought it should be extended and I didn't sense any
opposition, but this issue was never really discussed sufficiently, I don't
believe, to claim there was a conclusion.
The discussion was continuing as we ran out of time, so it will be
continued at the face-to-face next week, in one-half of the afternoon of
the Semantic Model time-slot (thanks Peter!). I will try in the next few
days to publish a list of ISSUEs as a result of the discussion today.
For those that were part of the discussion, if I have misrepresented or
forgotten anything, please post!
Dennis