Hey All...
We currently have our parameters in PSI defined mostly as Strings,
(jobProcessingAttributes for example), and are relying on the PWG SM schemas
to provide the strong typing for the structure that the string contains..
One option is to strongly type the parameters as a complex type rather than
a string... I hate to open up this can of worms, but... So far, I've heard
of 3 different approaches for this...
I've tried to summarize the advantages / disadvantages for each of the
approaches. Please add your thoughts to the discussion..
Dave
Strongly Typed WSDL Parameters Discussion
One of the discussions that has been going on is around our WSDL definition
of the PSI interfaces. There are three possibilities that have presented
themselves:
1) The parameters (for example, jobProcessingAttributes) should be encoded
as a string defined by a schema. Extensions are added within the XML
document...
2) The parameters should be encoded as a strongly typed complex type,
extensions are added as new, vendor defined elements.
3) The parameters should be encoded as a strongly typed complex type, where
the last parameter is a string[] of structures.
There are a number of advantages and dis-advantages to each which I have
tried to capture here:
1) String parameters defined by schema:
This is the current model for the PSI interface specification..
Advantages:
* Easily (understandably) extensible at the element level by
the application.
* Clients can code up only the elements that they wish to deal
with.
* Allows name-space extensions to the interfaces through the
QueryEndPoints mechanism. (ie, give me the JobControlInterface that
understands the pwg common semantic model, and give me the
JobControlInterface that understands the Digital Imaging semantic model.)
* Interoperability between toolkits. The simple types are
readily encoded / decoded by the toolkits.
* A 1.0 server (think existing printer that talks 1.0 psi)
would be able to interpret a 2.0 clients request. (Assuming the method
signatures didn't change - it would simply ignore the elements it did not
understand.)
* A 2.0 server (Think new print service) could interpret a 1.0
client request (Assuming no new mandatory elements were added...)
* A reference to the schema that defines the parameters can
simply be made in the interface documentation.
Disadvantages:
* We need to hand generate the serializers / deserializers
* Interoperability between devices is not enforced by a
strongly typed interface.
2) Complex type parameters
Advantages:
* Serializers and de-serializers generated by toolkits
automatically.
* Interoperability between devices is more enforced by the
strongly typed interface.
* Aligns with UPnP direction
Disadvantages:
* How to deal with the #any extensions in the toolkits?
(Thought is that you inherit from the toolkit generated serializer, and add
extensibility yourself)
* Toolkit incompatibilities (Thought to be somewhat mitigated
at this point.)
* A 2.0 client would not be able to talk to a 1.0 server, the
burden would be on the client to also be able to talk the 1.0 interface
specification.
3) Complex type parameters with string[] of structures element at the end
Advantages:
* Serializers and de-serializers generated by toolkits
automatically.
* Interoperability between devices is more enforced by the
strongly typed interface.
Disadvantages:
* Toolkit incompatibilities - structures within structures
have been problematic in the past. (Thought to be somewhat mitigated at
this point.)
* A 2.0 client would not be able to talk to a 1.0 server
(assuming new elements are added to the base definition), the burden would
be on the client to also be able to talk the 1.0 interface specification.
This archive was generated by hypermail 2b29 : Tue Oct 22 2002 - 13:55:50 EDT