[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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.=20 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" =20 That said: =20 Schema changes Given John's description of the proposed schema issues: =20 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. =20 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. =20 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. =20 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. =20 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. =20 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. =20 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). = 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. The UDDI's WSDL doesn't need = any change in this regard. =20 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. =20 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. 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. Luc Cl=E9ment Microsoft -----Original Message----- From: John Colgrave [mailto:colgrave@hursley.ibm.com = <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 = <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_work= group.php = <http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_wor= kgroup.php> . ------_=_NextPart_001_01C39068.099771C2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE></TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD> <BODY><!-- Converted from text/plain format --><FONT size=3D2> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book"><EM><FONT color=3D#0000ff>The opinions = that follow are=20 expressed as a member of the TC rather than that of my role as=20 co-chair.</FONT></EM> </FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><?xml:namespace = prefix =3D o ns =3D=20 "urn:schemas-microsoft-com:office:office" /><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">What a thread! I too apologize for the = long=20 mail.</FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">I think it would be fair to say that = current=20 versions of <?xml:namespace prefix =3D st1 ns =3D=20 "urn:schemas-microsoft-com:office:smarttags" /><st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-RPC are an imperfect match to UDDI = given the=20 WSDL and Schema features we are making usage of. By the sounds of it, = and from=20 the cheap seats, I=92m also hearing that current <st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-RPC limitations in this regard will = likely be=20 addressed over time. </FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">The problem that John is tacking relates = to those=20 who choose not to use (for Java code portability reasons presumably) = existing=20 Java-based SDKs (such as uddi4j), but rather choose to use = <st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-RPC to generate UDDI client code. = I=92m not=20 unsympathetic to this goal however I am having problems accepting that = current=20 limitations of a given platform would require UDDI to adapt to conform.=20 Furthermore, even if <st1:stockticker = w:st=3D"on">JAX</st1:stockticker>-RPC was=20 going to address its current limitations, imperfect <st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-PRC tooling would still present = problems; will=20 we need to address these also? Of course not, then why are changes to = our spec=20 being considered because of <st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-RPC? Nonetheless, this matter is = before us and=20 given the amount of discussion on this topic, we need to dispose of it.=20 </FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">In fairness to John and others on the = thread, the=20 idea of a TN (which by definition is non-normative) was proposed as a = way to=20 address this matter, and as such would not require a normative change to = the=20 spec. However, a TN will not suffice given the set of issues identified = by John=20 and therefore, we need to agree on guiding principles to use to bring = this=20 matter to a close. Let me propose some:</FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 = level1 lfo1; tab-stops: list .75in"><EM><SPAN=20 style=3D"FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic Book'; = mso-fareast-font-family: 'Franklin Gothic Book'; mso-bidi-font-family: = 'Franklin Gothic Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic"><SPAN=20 style=3D"mso-list: Ignore">a.<SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></SPAN></SPAN></EM><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: italic">We=20 need to remain true to the process we agreed to (</SPAN></EM><FONT=20 face=3D"Franklin Gothic Book">UDDI Spec TC Process, Section <EM><SPAN=20 style=3D"COLOR: navy; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: italic"><A=20 href=3D"tp://www.oasis-open.org/committees/uddi-spec/doc/process/uddi-spe= c-tc-process-20021212.htm#_Toc27444262"><SPAN=20 style=3D"mso-bidi-font-style: normal">1.6 Specification Change Request = and Errata=20 Process</SPAN></A></SPAN></EM></FONT><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic">):<o:p></o:p></SPAN></EM></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt 1in"><EM><SPAN=20 style=3D"FONT-FAMILY: 'Franklin Gothic Book'">From time to time, = <U>errors,=20 inconsistencies or ambiguities</U> will be discovered in a UDDI TC = Specification=20 or UDDI Standard based upon ongoing experience with the specification by = those=20 implementing it. Such feedback is essential to improving the quality of = these=20 documents. </SPAN></EM><I><BR><BR><EM><SPAN=20 style=3D"FONT-FAMILY: 'Franklin Gothic Book'">The specification change = request and=20 errata process is intended to <U>address defects</U> found in a=20 specification. <U>It may NOT be used to add new functionality or=20 substantively change existing functionality except as minimally required = to=20 effect a fix</U>. </SPAN></EM></I><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic"><o:p></o:p></SPAN></EM></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 = level1 lfo1; tab-stops: list .75in"><EM><SPAN=20 style=3D"FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic Book'; = mso-fareast-font-family: 'Franklin Gothic Book'; mso-bidi-font-family: = 'Franklin Gothic Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic"><SPAN=20 style=3D"mso-list: Ignore">b.<SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></SPAN></SPAN></EM><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: italic">A=20 change to the spec must be consistent with the WS-I=20 BP<o:p></o:p></SPAN></EM></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 = level1 lfo1; tab-stops: list .75in"><EM><SPAN=20 style=3D"FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic Book'; = mso-fareast-font-family: 'Franklin Gothic Book'; mso-bidi-font-family: = 'Franklin Gothic Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic"><SPAN=20 style=3D"mso-list: Ignore">c.<SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></SPAN></SPAN></EM><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: italic">The=20 content of a TN needs to be consistent with the UDDI spec and TC = approved TNs=20 and BPs; it should not contradict normative behaviour and simply offers = a=20 temporary work-around<o:p></o:p></SPAN></EM></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 = level1 lfo1; tab-stops: list .75in"><EM><SPAN=20 style=3D"FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic Book'; = mso-fareast-font-family: 'Franklin Gothic Book'; mso-bidi-font-family: = 'Franklin Gothic Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic"><SPAN=20 style=3D"mso-list: Ignore">d.<SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></SPAN></SPAN></EM><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: italic">The=20 TN which may result needs to clearly represent the view that it, and the = associated collateral, is non-normative and used to =93bridge the gap=94 = that=20 currently exists<o:p></o:p></SPAN></EM></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; mso-list: l0 = level1 lfo1; tab-stops: list .75in"><SPAN=20 style=3D"mso-fareast-font-family: 'Franklin Gothic Book'; = mso-bidi-font-family: 'Franklin Gothic Book'; mso-bidi-font-weight: = bold; mso-bidi-font-style: italic"><SPAN=20 style=3D"mso-list: Ignore"><FONT face=3D"Franklin Gothic = Book">e.</FONT><SPAN=20 style=3D"FONT: 7pt 'Times New = Roman'"> =20 </SPAN></SPAN></SPAN><EM><SPAN=20 style=3D"COLOR: black; FONT-STYLE: normal; FONT-FAMILY: 'Franklin Gothic = Book'; mso-bidi-font-weight: bold; mso-bidi-font-style: italic">The=20 TN should only =93patch=94 what=92s required and avoid making changes = that would make=20 it difficult to remove the =93patch=94 when <st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-RPC is =93fixed=94</SPAN></EM><SPAN=20 style=3D"COLOR: black; mso-bidi-font-weight: bold; mso-bidi-font-style: = italic"><o:p></o:p></SPAN></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">That said:</FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><B=20 style=3D"mso-bidi-font-weight: normal"><FONT face=3D"Franklin Gothic = Book">Schema=20 changes<o:p></o:p></FONT></B></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">Given John=92s description of the proposed = schema=20 issues:</FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'">The=20 first category is related to the use of constructs such as xsd:choice = that are=20 nor mandatory in <st1:stockticker w:st=3D"on">JAX</st1:stockticker>-RPC = 1.0.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>It is possible to replace the = use of=20 such constructs with a more lax approach using sequences of elements, = each of=20 which is optional.<SPAN style=3D"mso-spacerun: yes"> </SPAN>This = allows=20 applications to be developed which can generate invalid messages of = course, but=20 I am not aware of any environment that applies schema validation to a = message=20 being sent by a client, so even with the current schemas you cannot = guarantee=20 that a client will never send an invalid message so this is not = introducing any=20 new problem.<o:p></o:p></SPAN></I></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'"><o:p> </o:p></SPAN></I></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'">The=20 second category is related to elements/types that have been introduced = only to=20 limit string lengths etc. such as validationTypeString255.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>These currently show up in the = generated=20 programming model, which is ugly.<SPAN style=3D"mso-spacerun: = yes"> =20 </SPAN>In this case also, I am not aware of this checking being applied = to=20 outbound messages from a client, so nothing is lost by removing these = and just=20 using the base types such as string.<o:p></o:p></SPAN></I></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'"><o:p> </o:p></SPAN></I></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'">The=20 third category is related to things that are supported in a proprietary = way,=20 which obviously limits application portability.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>If my memory serves, these can = be=20 avoided by an approach similar to that for the second category, and = replacing=20 something like NMTOKEN with string.<o:p></o:p></SPAN></I></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'"><o:p> </o:p></SPAN></I></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'">The=20 fourth category is for things such as extensions of xsd:boolean that I = do not=20 think add any value and again show up as unnecessary complications in = the=20 generated code.<SPAN style=3D"mso-spacerun: yes"> </SPAN>An = example of this=20 is truncated.<SPAN style=3D"mso-spacerun: yes"> </SPAN>I think = that it is=20 highly unlikely that anyone will want to extend truncated beyond simply = true and=20 false.<o:p></o:p></SPAN></I></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">I see the first and third category = (xsd:choice and=20 application portability issues) as something that a TN could consider=20 addressing. However, I don=92t think that the second and fourth category = merit=20 mention in a TN, and am concerned that doing so would make it difficult = for the=20 Java community to make a transition back once <st1:stockticker=20 w:st=3D"on">JAX</st1:stockticker>-RPC (and tooling) addresses its = limitations wrt=20 schema. TN authors and the TC should adamantly resist this as it would = promote=20 continued divergence from the normative spec. In short, only =93patch=94 = what=92s=20 required; removing the patch should be as painless as possible and = should be met=20 with as little resistance as possible from the UDDI Java developer=20 community.</FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><B=20 style=3D"mso-bidi-font-weight: normal"><FONT=20 face=3D"Franklin Gothic Book">WSDL<o:p></o:p></FONT></B></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'">The=20 first of these is that <U>WSDL service and port definitions need to be=20 created</U>, as these affect the Java programming model.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>Unfortunately this means that = a=20 default/dummy endpoint has to be supplied for each port but the user can = supply=20 the correct one at runtime.<o:p></o:p></SPAN></I></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">I=92m having a great amount of difficulty = accepting=20 this. This goes counter to what we=92ve been advocating and published = (i.e. WSDL=20 v2 TN). This is not a <st1:stockticker = w:st=3D"on">JAX</st1:stockticker>-RPC issue=20 that will take a significant amount of time to address because of the=20 <st1:stockticker w:st=3D"on">JCP</st1:stockticker> process, but rather, = it=92s a=20 limitation of tooling; tooling simply needs to get fixed. The UDDI=92s = WSDL=20 doesn=92t need any change in this regard.</FONT></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal=20 style=3D"MARGIN: 0in 0in 0pt 0.5in; mso-layout-grid-align: none"><I=20 style=3D"mso-bidi-font-style: normal"><SPAN=20 style=3D"FONT-SIZE: 8pt; COLOR: #333399; FONT-FAMILY: 'Lucida Sans = Unicode'">The=20 second is that we need to change the element used to indicate success on = calls=20 such as delete_tModel that currently use dispositionReport, as Java does = not=20 like the same element being used as both a normal output and a = fault.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>I have created an empty = success element=20 for this case, as mentioned in the WS-I Basic Profile.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>This will require a change to = the UDDI=20 specification and possibly a change in implementations.<SPAN=20 style=3D"mso-spacerun: yes"> </SPAN>My experiments indicate that = the=20 implementations do not have to change, and if a dispositionReport is = returned=20 when the Java is not expecting one, it is simply ignored, but we may not = be able=20 to rely on this.<SPAN style=3D"mso-spacerun: yes"> </SPAN>This = change is the=20 most significant one and may require a publication of a 3.1.1 spec. or=20 something.<o:p></o:p></SPAN></I></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT=20 face=3D"Franklin Gothic Book"> </FONT></o:p></P> <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20 face=3D"Franklin Gothic Book">This is definitively a bigger issue! I am = also=20 apprehensive of considering this type of change particularly if UDDI = conforms to=20 the WS-I BP; am I wrong? Unless UDDI is inconsistent with WS-I BP in = this=20 regard, I don=92t see why we should consider making such a change. = I=92ll reiterate,=20 if indeed some Java tooling in the future isn=92t able to handle this, = it=92s a=20 problem with that tool that should be fixed.</FONT></P> <P><!-- Converted from text/rtf format --></P> <P><FONT face=3D"Franklin Gothic Book" size=3D2>Luc=20 Cl=E9ment<BR>Microsoft</FONT><BR><BR><FONT face=3DArial>-----Original=20 Message-----<BR>From: John Colgrave [</FONT><A=20 href=3D"mailto:colgrave@hursley.ibm.com";><FONT=20 face=3DArial>mailto:colgrave@hursley.ibm.com</FONT></A><FONT = face=3DArial>]<BR>Sent:=20 Wednesday, October 08, 2003 07:31<BR>To: 'Daniel Feygin'; 'Matthew J. = Dovey';=20 'Ugo Corda'; 'Anne Thomas Manes'; 'UDDI Spec TC'<BR>Subject: RE: = [uddi-spec]=20 Changes to UDDI Schemas and WSDL to support code generation<BR><BR>I = think that=20 JAX-RPC 1.1 will be better than 1.0, but I think that the major issues = will=20 remain even in 1.1, and I don't know when 1.1-based tools will appear, = so I=20 think that if we were to do something in the near future that 1.0 would = have to=20 be the target. Of course, once 1.1-based tools appear we could = version the=20 TN and the tool-friendly schemas, as Daniel points out, and move them = back a=20 little towards the normative schemas.<BR><BR>I would hope that the = programming=20 model we aimed at with 1.0 would be compatible with what we would get = with 1.1=20 with fewer schema changes.<BR><BR>I do think that eventually the need = for these=20 tool-friendly schemas will disappear (at least until we get a new = version of=20 Schema) as hopefully all tools will converge on full schema support, so = they=20 should be viewed as a short-term expedient rather than a long-term=20 strategy.<BR><BR>John Colgrave<BR>IBM<BR><BR><BR>> -----Original=20 Message-----<BR>> From: Daniel Feygin [</FONT><A=20 href=3D"mailto:feygin@unitspace.com";><FONT=20 face=3DArial>mailto:feygin@unitspace.com</FONT></A><FONT = face=3DArial>]<BR>>=20 Sent: 06 October 2003 15:31<BR>> To: 'Matthew J. Dovey'; 'Ugo Corda'; = 'Anne=20 Thomas Manes'; 'John<BR>> Colgrave'; 'UDDI Spec TC'<BR>> Subject: = RE:=20 [uddi-spec] Changes to UDDI Schemas and WSDL to support<BR>> code=20 generation<BR>><BR>> > The problem is that we are chasing a = moving=20 target. As Anne and Ugo<BR>> > have pointed out JAX-RPC is moving = towards=20 a more WS-I compliant<BR>> > version (and I'm not sure whether = John was=20 basing his analysis on<BR>> > JAX-RPC 1.0 or 1.1), so it might be = that we=20 spend time addressing<BR>> > issues which turn out no longer to be = issues.<BR>><BR>> This is exactly why I thought the alternative = schema=20 should not have<BR>> normative status. At the same time we know = that we=20 need to make a<BR>> simpler schema, because this entire discussion = originated=20 out of the<BR>> need to support a particular popular platform. = We know=20 that it is not<BR>> there just yet, but we are aware that at some = point it is=20 likely to<BR>> get there (I'm referring to JAX-RPC's spotty XML = Schema=20 support). A<BR>> BP or a TN can be produced to correspond to a=20 particular version of a<BR>> particular technology without us having = to=20 version the normative<BR>> schema and WSDL whenever these = technologies mature=20 to a new level of<BR>> standards support.<BR>><BR>> > My = point about=20 clients and servers not being consistent about what<BR>> > XML = they=20 validate, is due to the fact that I am uncomfortable having<BR>> > = two=20 non-isomorphic schemas for the same namespace.<BR>><BR>> The = inconsistency=20 you are pointing to arises out of the fact that<BR>> standards are = not=20 implemented consistently. IMHO, XML instances based<BR>> on = both=20 schemas would correctly exist in the same namespace as they<BR>> are=20 instances of the same object as described in the spec or in the<BR>>=20 normative schema.<BR>><BR>> > Matthew<BR>><BR>>=20 Daniel<BR><BR><BR>To unsubscribe from this mailing list (and be removed = from the=20 roster of the OASIS TC), go to </FONT><A=20 href=3D"http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/le= ave_workgroup.php"><FONT=20 face=3DArial>http://www.oasis-open.org/apps/org/workgroup/uddi-spec/membe= rs/leave_workgroup.php</FONT></A><FONT=20 face=3DArial>.<BR><BR><BR></FONT></FONT></P></BODY></HTML> ------_=_NextPart_001_01C39068.099771C2-- --------------InterScan_NT_MIME_Boundary--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]