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: 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



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