-----Original
Message-----
From: Luc
Clement [mailto:lclement@windows.microsoft.com]
Sent: 12 October 2003 03:25
To: John Colgrave; Daniel Feygin;
Matthew J. Dovey; Ugo Corda; Anne Thomas Manes; UDDI Spec TC
Subject: RE: [uddi-spec] Changes to
UDDI Schemas and WSDL to support code generation
The
opinions that follow are expressed as a member of the TC rather than that of
my role as co-chair.
What a thread!
I too apologize for the long mail.
I think it
would be fair to say that current versions of JAX-RPC are an imperfect match to UDDI given
the WSDL and Schema features we are making usage of. By the sounds of it,
and from the cheap seats, I’m also hearing that current JAX-RPC limitations in this regard will likely
be addressed over time.
The problem
that John is tacking relates to those who choose not to use (for Java code
portability reasons presumably) existing Java-based SDKs (such as uddi4j),
but rather choose to use JAX-RPC to generate UDDI client code. I’m not
unsympathetic to this goal however I am having problems accepting that
current limitations of a given platform would require UDDI to adapt to
conform. Furthermore, even if JAX-RPC was going to address its current
limitations, imperfect JAX-PRC
tooling would still present problems; will we need to address these also? Of
course not, then why are changes to our spec being considered because of
JAX-RPC? Nonetheless, this
matter is before us and given the amount of discussion on this topic, we
need to dispose of it.
In fairness to
John and others on the thread, the idea of a TN (which by definition is
non-normative) was proposed as a way to address this matter, and as such
would not require a normative change to the spec. However, a TN will not
suffice given the set of issues identified by John and therefore, we need to
agree on guiding principles to use to bring this matter to a close. Let me
propose some:
a.
We
need to remain true to the process we agreed to
(UDDI Spec TC Process, Section
1.6
Specification Change Request and Errata
Process):
From time to
time, errors, inconsistencies or ambiguities will be discovered in a
UDDI TC Specification or UDDI Standard based upon ongoing experience with
the specification by those implementing it. Such feedback is essential to
improving the quality of these
documents.
The specification change request
and errata process is intended to address defects found in a
specification. It may NOT be used to add new functionality or
substantively change existing functionality except as minimally required to
effect a fix.
b.
A
change to the spec must be consistent with the WS-I
BP
c.
The
content of a TN needs to be consistent with the UDDI spec and TC approved
TNs and BPs; it should not contradict normative behaviour and simply offers
a temporary work-around
d.
The
TN which may result needs to clearly represent the view that it, and the
associated collateral, is non-normative and used to “bridge the gap” that
currently exists
e.
The
TN should only “patch” what’s required and avoid making changes that would
make it difficult to remove the “patch” when JAX-RPC is “fixed”
That
said:
Schema
changes
Given John’s
description of the proposed schema issues:
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.
I see the first
and third category (xsd:choice and application portability issues) as
something that a TN could consider addressing. However, I don’t think that
the second and fourth category merit mention in a TN, and am concerned that
doing so would make it difficult for the Java community to make a transition
back once JAX-RPC (and
tooling) addresses its limitations wrt schema. TN authors and the TC should
adamantly resist this as it would promote continued divergence from the
normative spec. In short, only “patch” what’s required; removing the patch
should be as painless as possible and should be met with as little
resistance as possible from the UDDI Java developer community.<JC>I think there is a certain
amount of trying to second-guess what will happen with JAX-RPC 2.0 and, in
particular, JAXB 2.0 as far as the second and fourth categories are
concerned, although as I said with respect to the fourth category I am not
sure that there is any value in having extensions of boolean. What was
the reason for defining elements such as truncated? However, as more
“aesthetic” items, I could live with not making those
changes.</JC>
WSDL
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.
I’m having a
great amount of difficulty accepting this. This goes counter to what we’ve
been advocating and published (i.e. WSDL v2 TN). <JC>I don’t understand this comment. Can you
elaborate? The impact of the WSDL service and port on the Java
programming model was discussed at some length during the production of the
WSDL v2 TN.</JC>This is not a JAX-RPC issue that will take a significant
amount of time to address because of the JCP process, but rather, it’s a limitation of
tooling; tooling simply needs to get fixed. <JC>I disagree, it is an aspect of the generation
of Java from WSDL as specified by JAX-RPC. It is not a tooling issue
and I am not sure that it will ever be “addressed” via the JCP, which is why
I think it is a strategic change, at least until we see what emerges as WSDL
1.2.</JC>The UDDI’s WSDL doesn’t need any change in this
regard.<JC>This is not a
change but an addition.</JC>
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.
This is
definitively a bigger issue! I am also apprehensive of considering this type
of change particularly if UDDI conforms to the WS-I BP; am I wrong? Unless
UDDI is inconsistent with WS-I BP in this regard, I don’t see why we should
consider making such a change. <JC>It is too strong to say that UDDI is
inconsistent with the WS-I BP but, as I mentioned in my original note, the
BP explicitly mentions the use of an empty body/message/part when no
information is being returned, which is the case where we currently use a
dispositionReport with a single success value. There is no useful
information in the dispositionReport, it is merely the absence of a fault
that indicates that the operation succeeded, so I think that this usage can
be replaced by an empty message with no loss of information. This is
the most significant change in that it requires changes to the specification
and implementations but it is a fairly simple
change.</JC>I’ll reiterate, if indeed some Java tooling
in the future isn’t able to handle this, it’s a problem with that tool that
should be fixed.<JC>I don’t
think this is a question of whether or not some Java tooling can or can’t
handle this, I think it is a question of what the relevant Java
specifications require.</JC>
Luc
Clément
Microsoft
-----Original
Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Wednesday, October
08, 2003 07:31
To: 'Daniel Feygin'; 'Matthew J. Dovey'; 'Ugo Corda';
'Anne Thomas Manes'; 'UDDI Spec TC'
Subject: RE: [uddi-spec] Changes to
UDDI Schemas and WSDL to support code generation
I think that JAX-RPC
1.1 will be better than 1.0, but I think that the major issues will remain
even in 1.1, and I don't know when 1.1-based tools will appear, so I think
that if we were to do something in the near future that 1.0 would have to be
the target. Of course, once 1.1-based tools appear we could version
the TN and the tool-friendly schemas, as Daniel points out, and move them
back a little towards the normative schemas.
I would hope that the
programming model we aimed at with 1.0 would be compatible with what we
would get with 1.1 with fewer schema changes.
I do think that
eventually the need for these tool-friendly schemas will disappear (at least
until we get a new version of Schema) as hopefully all tools will converge
on full schema support, so they should be viewed as a short-term expedient
rather than a long-term strategy.
John
Colgrave
IBM
> -----Original Message-----
> From:
Daniel Feygin [mailto:feygin@unitspace.com]
> Sent: 06 October 2003
15:31
> To: 'Matthew J. Dovey'; 'Ugo Corda'; 'Anne Thomas Manes';
'John
> Colgrave'; 'UDDI Spec TC'
> Subject: RE: [uddi-spec]
Changes to UDDI Schemas and WSDL to support
> code
generation
>
> > The problem is that we are chasing a moving
target. As Anne and Ugo
> > have pointed out JAX-RPC is moving
towards a more WS-I compliant
> > version (and I'm not sure whether
John was basing his analysis on
> > JAX-RPC 1.0 or 1.1), so it
might be that we spend time addressing
> > issues which turn out no
longer to be issues.
>
> This is exactly why I thought the
alternative schema should not have
> normative status. At the
same time we know that we need to make a
> simpler schema, because
this entire discussion originated out of the
> need to support a
particular popular platform. We know that it is not
> there just
yet, but we are aware that at some point it is likely to
> get there
(I'm referring to JAX-RPC's spotty XML Schema support). A
> BP
or a TN can be produced to correspond to a particular version of a
>
particular technology without us having to version the normative
>
schema and WSDL whenever these technologies mature to a new level of
>
standards support.
>
> > My point about clients and servers
not being consistent about what
> > XML they validate, is due to
the fact that I am uncomfortable having
> > two non-isomorphic
schemas for the same namespace.
>
> The inconsistency you are
pointing to arises out of the fact that
> standards are not
implemented consistently. IMHO, XML instances based
> on both
schemas would correctly exist in the same namespace as they
> are
instances of the same object as described in the spec or in the
>
normative schema.
>
> > Matthew
>
>
Daniel
To unsubscribe from this mailing list (and be removed from
the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.