IEEE-ISTO/PWG/SM3/F2F Meeting Minutes. (Wed May 14, 2014). 9:00 - 5:00 PM
Attendees:
Rick Yardumian (Canon)
Michael Sweet (Apple)
Joe Murdock (Sharp)
Bill Wagner (TIC)
Jeremy Leber (Lexmark)
Russell Brudnicki (Kyocera)
Ira McDonald (High North) - on phone
Paul Tykodi (TCS) - on phone
Rainer Prosi (Heidelberg/JDF rep) - on phone
Daniel Manchala (Xerox)
The morning session was spent on the JDFMAP (a mapping of the JDF mapping to PWG PJT). A comparison of each attribute in the mapping document was discussed. These changes are available at:
ftp://ftp.pwg.org/pub/pwg/sm3/wd/wd-smjdfmap10-20140430-rp.pdf (Comments from Rainer Prosi)
ftp://ftp.pwg.org/pub/pwg/sm3/wd/wd-sm3-jdfmap-comments-20140514-ry-dm.docx (combined comments from Rick Y and Daniel M)
ftp://ftp.pwg.org/pub/pwg/sm3/wd/wd-sm3-jdfmap-comments-20140514-ry-dm.pdf<ftp://ftp.pwg.org/pub/pwg/sm3/wd/wd-smjdfmap10-20140430-rp.pdf>
Rest of the mapping document will be discussed in the SM3 WG meetings (perhaps change the time from 9:00 AM - 12:00 PM PT).
The afternoon session focused on the structure of the SM3 document (being separated into 3+2 specifications - the latter two need to be looked at in view of the new SM3 spec). The outline of the specs is available at :
ftp://ftp.pwg.org/pub/pwg/sm3/wd/wd-sm3-specifications-outline-20140514.docx and
ftp://ftp.pwg.org/pub/pwg/sm3/wd/wd-sm3-specifications-outline-20140514.pdf
Briefly, the various specs are:
Specification 1: Semantic Model: Imaging System
Specification 2: Semantic Model: Subunits
Specification 3: Semantic Model: Jobs & Documents
Specification 4: Semantic Model: Counters & Timers (~ PWG 5106.1-2007)
Specification 5: Semantic Model: Power (~ PWG 5106.4-2011)
Resolve issues raised by Bill
1. The schema approach for the operations currently has service type specific operations. That is, each Service type has a separate set of operations, labeled with that service type, although most operations are functionally common to all service types. The MFD Model specification (SM2) labels the operations with a <service> insert, indicating that the specific service type is to be inserted. The specific destination service is identified as an element in each operation, so is the service type needed in the service name? {Resolution: Remove the <service> insert. Note: Resource and Service Control are the only 2 services that do not have a Job Model.}
2. Roles of the entities that initiated the operations are: Client/User, Proxy, Administrator.
3. The current schema uses the same element names for distinctly different elements. On one level, the terms State, StateMessages, StateReasons for example are used with respect to the System and each Service (although the element data types are consistent). On a different level, the same element names referring to certain capabilities is used both as a Boolean and as a different data type (e.g, Brightness, Sharpness, Contrast, Subject, To). The former use is probably benign, but might the latter cause some confusion?{Resolution: We need to further discuss the *-default, -supported, -ready and -capabilities in the next WG meeting.}
Joe Murdock created IDS related .xsd files to be integrated into the SM3 schema.
Our next conference call is June 9, 2014 at 3pm ET.