[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Restructuring the UDDI Schemas and WSDL
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]