Ira,
Comments below
Pete
Peter Zehler
XEROX
Xerox Innovation Group
Email: PZehler@crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 422-7961
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Thursday, July 15, 2004 12:11 PM
To: 'ps@pwg.org'
Subject: RE: PS> Last call ready Events schema v0.41 (14 July 2004)
Hi Pete,
Thanks for all these criticisms. I'll pore over them
and try to understand them quickly.
There are three real problems I think I see:
(1) Events.xsd MUST always be completely stand-alone,
because it will in the future become the direct
authoritative reference for Std Imaging System
Events. Importing the document events from
WKV is not acceptable.
<PZ>I'm not advocating the inclusion of PwgWellKnownValues. I just inclided
it as an example of the pattern for a qualified NMTOKEN</PZ>
(2) Introducing the use of 'union'.
There is very strong resistance to this in the
PSI WG. The existence of 'union' in SM/1.0
causes more problems than it might solve.
<PZ>The only thing given up is that the PWG can not add new values unless
there is a major version bump or it adds them to the vendor element. It is
your guys call. In the rest of the schema we decided not to code it based
on the capabilities of existing tools. We decided to define it as called
out in the model. You know my preference but I will not strongly object</PZ>
[For the PSI WSDL to be reviewed and/or tested,
a version of every SM/1.0 schema without 'union'
must be created and stored in a PSI WG directory.]
(3) There is no concept of type II or type III enums
in Events.xsd. Events are all type I. Any other
event is a vendor extension. Period.
<PZ>As I said if events are type I there is no need for a union construct.
I would prefer to see the enumerations not inlined and be defined in an
xxxWKV element. The resulting change is that simple types
DocumentEventType, JobEventType, PrinterEventType, SubunitEventType would
be changed to simple types DocumentEventWKV, JobEventWKV, PrinterEventWKV,
SubunitEventWKV. The VendorEventType would have the pattern facet added to
its restriction as shown below and its name would change to
VendorEventExtensionPattern.</PZ>
[By the way, type III enums no longer exist in
IPP. The IETF has definitively rejected the
type III class in Printer/Finisher MIB and passed
that on to IANA for IPP as well. SM should stop
using the term "type III"]
Cheers,
- Ira
PS - We're on a short fuse here. If Events.xsd is
not in final form before 26 July 2004, then PSI/1.0
'last call' is prevented.
<PZ>my proposal is to skip the union stuff, add the pattern and change the
names as suggested above</PZ>
Ira McDonald (Musician / Software Architect)
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: Zehler, Peter [mailto:PZehler@crt.xerox.com]
Sent: Thursday, July 15, 2004 8:15 AM
To: 'McDonald, Ira'; 'ps@pwg.org'
Subject: RE: PS> Last call ready Events schema v0.41 (14 July 2004)
Ira,
One thing I noticed is that VendorEventType values (i.e. extensions) are not
federated through the use of namespaces. The way this is handled in the
rest of the PWG schema is a restriction that requires a ':' in the value.
To accomplish this the definition would change from:
<xsd:simpleType name="VendorEventType">
<xsd:restriction base="xsd:NMTOKEN"/>
<!-- vendor event type - for site or vendor extensions -->
<!-- see PWG Print Service Interface/1.0 [PWG-PSI] -->
</xsd:simpleType>
to:
<xsd:simpleType name="VendorEventType">
<xsd:restriction base="xsd:NMTOKEN">
<!-- vendor event type - for site or vendor extensions -->
<!-- see PWG Print Service Interface/1.0 [PWG-PSI] -->
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="\w+:[\w_\-\.]+"/>
</xsd:restriction>
</xsd:simpleType>
The other thing I noticed is that since the events are specified as
enumerations a major revision will be necessary to add any new values. The
way the rest of the schema handles this is through the use of a union. If
the intent is these are a type I enumeration the definition is fine. If
they are type II or III enumerations the definitions should be changed.
For example DocumentEventType would change from:
<xsd:simpleType name="DocumentEventType">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="DocumentStateChanged"/>
<xsd:enumeration value="DocumentStateOnlyChanged"/>
<xsd:enumeration value="DocumentCreated"/>
<xsd:enumeration value="DocumentCompleted"/>
<xsd:enumeration value="DocumentConfigChanged"/>
<xsd:enumeration value="DocumentProgress"/>
<xsd:enumeration value="DocumentError"/>
<xsd:enumeration value="DocumentWarning"/>
</xsd:restriction>
<!-- document event type - derived from job event type -->
<!-- see PWG Print Service Interface/1.0 [PWG-PSI] -->
<!-- see document-state - section 9.1.25 [PWG5100.5] -->
<!-- see document-state-message - section 9.1.26 [PWG5100.5]
-->
<!-- see document-state-reasons - section 9.1.27 [PWG5100.5]
-->
</xsd:simpleType>
To (Note DocumentEventTypes not required and can be replaced with
DocumentEventWKVs):
<xsd:simpleType name="DocumentEventWKVs">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="DocumentStateChanged"/>
<xsd:enumeration value="DocumentStateOnlyChanged"/>
<xsd:enumeration value="DocumentCreated"/>
<xsd:enumeration value="DocumentCompleted"/>
<xsd:enumeration value="DocumentConfigChanged"/>
<xsd:enumeration value="DocumentProgress"/>
<xsd:enumeration value="DocumentError"/>
<xsd:enumeration value="DocumentWarning"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DocumentEventType">
<xsd:restriction base="DocumentEventWKVs"/>
</xsd:simpleType>
<xsd:complexType name="DocumentEvents">
<xsd:sequence>
<xsd:element name="DocumentEvent" minOccurs="0"
maxOccurs="unbounded">
<xsd:simpleType>
<xsd:union memberTypes="DocumentEventType
KeywordNsExtensionPattern"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="VendorEvent" type="VendorEventType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<!-- list of document events -->
</xsd:complexType>
(from PwgWellKnownValues:
<xsd:simpleType name="KeywordNsExtensionPattern">
<xsd:restriction base="xsd:NMTOKEN">
<xsd:pattern value="\w+:[\w_\-\.]+"/>
</xsd:restriction>
</xsd:simpleType>
)
Pete
Peter Zehler
XEROX
Xerox Innovation Group
Email: PZehler@crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 422-7961
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
Sent: Wednesday, July 14, 2004 6:35 PM
To: 'ps@pwg.org'
Subject: PS> Last call ready Events schema v0.41 (14 July 2004)
Hi folks, Wednesday (14 July 2004)
Ready for PWG 'last call', I just posted the Events XML schema v0.41
in the PSI working group directory tree. It validates without
warnings using XML SPY 2004, XRay 2.0, and XSV 2.5 (the free XML Schema
Validator):
ftp://ftp.pwg.org/pub/pwg/ps/schemas/events-20040714.xsd
NOTE: The _next_ version of PSI/1.0 (for PWG 'last call') will include
definitions of standard print system events in a new Appendix. This
Events schema references that (to be published) version of PSI/1.0.
**** We intend to submit PSI/1.0 and this companion Events schema for
PWG 'last call' no later than 26 July 2004, for conclusion at the
Plenary on Wednesday 18 August 2004 at the PWG face-to-face in Montreal.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
------------------------------------------------------------------------
[changes from Events v0.40 to v0.41]
(1) Minor editorial changes.
(2) Added standard PWG SM/1.0 target namespace to schema declaration,
per request of Masonori Itoh (Ricoh).
(3) Added type names (e.g., <xsd:complexType name="JobEvents">) to all
event groups (e.g., JobEvents), for support of PSI parameters,
per PSI WG telecon 6 July 2004.
(4) Added normative reference to PSI/1.0 spec for event definitions
(new appendix to be added w/ Std Print System Events spec content),
per PSI WG telecon 6 July 2004.
(5) Added detailed informative references to IPP/1.1 (RFC 2911),
IPP Document Object (PWG 5100.5), Printer MIB v2 (RFC 3805), and
IPP Event Notifications and Subscriptions (IESG-approved),
for implementor convenience.
------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Thu Jul 15 2004 - 19:56:00 EDT