Semantic Model Mail Archive: RE: SM> ACT - Summary of today'

Semantic Model Mail Archive: RE: SM> ACT - Summary of today'

RE: SM> ACT - Summary of today's discussion of the "-actual" prop osal

From: Hastings, Tom N (
Date: Wed Nov 06 2002 - 19:08:29 EST

  • Next message: Hastings, Tom N: "RE: SM> ACT - IPP "-actual" attributes downloaded, version 0.1 [m y comments]"


    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:




      one-sided, two-sides-long-edge, two-sides-short-edge

      one-sided, two-sides-long-edge, two-sides-short-edge

    would become:


    <sides context="actual">

    <sides context="default">

    <sides context="ready">
      one-sided, two-sides-long-edge, two-sides-short-edge

    <sides context="supported">
      one-sided, two-sides-long-edge, two-sides-short-edge


    -----Original Message-----
    From: []
    Sent: Friday, November 01, 2002 05:33
    To: Dennis Carney
    Subject: Re: SM> ACT - Summary of today's discussion of the "-actual"

    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



                        Carney" To:

                        <dcarney@us.ib cc:

              > Subject: SM> ACT - Summary of
    today's discussion
                        Sent by: of the "-actual" proposal






                        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'
    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?
    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!


    This archive was generated by hypermail 2b29 : Wed Nov 06 2002 - 19:08:50 EST