OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [no subject]


The schema changes fall into several different categories.

The first category is related to the use of constructs such as =
xsd:choice
that are nor mandatory in JAX-RPC 1.0.  It is possible to replace the =
use of
such constructs with a more lax approach using sequences of elements, =
each
of which is optional.  This allows applications to be developed which =
can
generate invalid messages of course, but I am not aware of any =
environment
that applies schema validation to a message being sent by a client, so =
even
with the current schemas you cannot guarantee that a client will never =
send
an invalid message so this is not introducing any new problem.

The second category is related to elements/types that have been =
introduced
only to limit string lengths etc. such as validationTypeString255.  =
These
currently show up in the generated programming model, which is ugly.  In
this case also, I am not aware of this checking being applied to =
outbound
messages from a client, so nothing is lost by removing these and just =
using
the base types such as string.

The third category is related to things that are supported in a =
proprietary
way, which obviously limits application portability.  If my memory =
serves,
these can be avoided by an approach similar to that for the second =
category,
and replacing something like NMTOKEN with string.

The fourth category is for things such as extensions of xsd:boolean that =
I
do not think add any value and again show up as unnecessary =
complications in
the generated code.  An example of this is truncated.  I think that it =
is
highly unlikely that anyone will want to extend truncated beyond simply =
true
and false.

There are also a couple of things that need to be added/changed to the =
UDDI
WSDL.  These changes to the WSDL are "strategic", by which I mean that I =
see
no sign of them ever not being required.

The first of these is that WSDL service and port definitions need to be
created, as these affect the Java programming model.  Unfortunately this
means that a default/dummy endpoint has to be supplied for each port but =
the
user can supply the correct one at runtime.

The second is that we need to change the element used to indicate =
success on
calls such as delete_tModel that currently use dispositionReport, as =
Java
does not like the same element being used as both a normal output and a
fault.  I have created an empty success element for this case, as =
mentioned
in the WS-I Basic Profile.  This will require a change to the UDDI
specification and possibly a change in implementations.  My experiments
indicate that the implementations do not have to change, and if a
dispositionReport is returned when the Java is not expecting one, it is
simply ignored, but we may not be able to rely on this.  This change is =
the
most significant one and may require a publication of a 3.1.1 spec. or
something.

John Colgrave
IBM





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]