[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]