RE: [uddi-spec] Restructuring the UDDI Schemas and WSDL

["Luc Clement" <lclement@windows.microsoft.com>]

Please, let's exercise constraint. This type of change should not be considered lightly and certainly does not qualify for inclusion in 3.0.1. Daniel I'm sure that you really didn't mean to "slip" it in .... sounds like a slip of the tougue.

Let me remind all of the "Specification Change Request and Errata Process" we've adopted (http://www.oasis-open.org/committees/uddi-spec/doc/process/uddi-spec-tc-process-20021212.htm#_Toc27444262):

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. 

When an error is discovered in one of the UDDI specifications or related documents, the person discovering it should post to the uddi-spec mailing list if he/she is a UDDI Spec TC member or to the public uddi-spec-comment mailing list if they are not.  In the latter case, debate on the uddi-spec-comment mailing list shall be sufficient to determine that the problem is valid and requires attention by the TC.  The TC shall consider the issue, debate it, and reach agreement that it justifies a change to the specification.  Such debate should occur on the uddi-spec mailing list..

When a consensus appears to be reached, the TC Chairs will inform the person having made the discovery to prepare a Specification Change Request (CR) and submit it, or in the case where the individual is not a member of the TC, the TC Chairs will delegate this responsibility to a TC member; IPR rules should be reiterated at that time by the TC Chairs.

Luc Clément
Microsoft
Co-chair, OASIS UDDI Spec TC

-----Original Message-----
From: Daniel Feygin [mailto:feygin@unitspace.com]
Sent: Wednesday, October 08, 2003 08:44
To: 'UDDI Spec TC'
Subject: RE: [uddi-spec] Restructuring the UDDI Schemas and WSDL

Why wait till V4 to do this?  If it's just clean-up then we can slip this into 3.0.1 (or 3.1?).

Daniel

> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Wednesday, October 08, 2003 7:30 PM
> To: 'UDDI Spec TC'
> Subject: [uddi-spec] Restructuring the UDDI Schemas and WSDL
>
>
> This is not related to the code-generation issue.
>
> I have been looking at restructuring the UDDI schemas and WSDL to make
> it clearer what is the core registry content and what is related to
> one or more APIs.
>
> I have started to put together an initial "V4" description of UDDI
> which is based on the V3 description but with an OASIS-style namespace
> and restructured to factor out elements into the appropriate place.
>
> I have a four-tier structure at the moment.
>
> The foundation is uddi_v4_im.xsd (the "im" stands for "information
> model") which is basically tModel, businessEntity and everything that
> those elements reference.
> I have adopted a style of using local anonymous types wherever
> possible and the combination of adopting this style and omitting those
> elements and types that are only used in the definition of one or more
> APIs results in a core schema that is around one third the size of
> uddi_v3.xsd.
>
> The next layer up is uddi_v4_common.wsdl which contains some types
> that are used in more than one API, and corresponding message
> definitions.  This file does a schema import of uddi_v4_im.xsd within
> the types section.
>
> The next layer up is a set of portType WSDL files, I have only done
> uddi_v4_publish_portType.wsdl.  Each of these portType files has a
> types section that defines types unique to that portType, a
> corresponding set of message definitions for those types, and then a
> single portType.  Each file does a wsdl import of uddi_v4_common.wsdl
> and a schema import of uddi_v4_im.xsd within the types section.
>
> The final layer is a set of binding WSDL files, I have only done
> uddi_v4_publish_binding.wsdl.  These are pretty much the same as the
> V3 ones.  Each binding WSDL file does a wsdl import of the
> corresponding portType WSDL file and defines a single SOAP/HTTP
> binding for that portType.
>
> I know it is difficult to visualize this without seeing it so if there
> is sufficient interest I will put together a "4.0.1"
> version of what I have done based on the final 3.0.1 schemas and make
> that available.
>
> John Colgrave
> IBM
>
>
>
>
> 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.



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.