[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 Subscription API
As pointed out by Claus, the consideration of the second alternative was certainly erroneous. It is particularly strange that I managed to propose it despite explicitly stating in 4.1 that "There may be no Inquiry API response message when subscriptionResultsList is used to report on deleted and/or virtually deleted (those no longer satisfying the defined filtering criteria) entities via keyBag structure." Updated CR with one fewer alternatives is attached. Daniel > -----Original Message----- > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] > Sent: Friday, November 22, 2002 3:25 PM > To: 'Daniel Feygin'; uddi-spec@lists.oasis-open.org > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 > Subscription API > > > Hi Daniel, > > The approach of your second alternative seems not to be a > valid one. The subscriptionResultsList can actually be empty, > that is, it contains neither an API response structure nor a > keyBag if there aren't any results as far as the subscription > is concerned. As a result, I prefer to stay with the proposal > outlined in section 4 of your change request. > > Claus > > -----Original Message----- > From: Daniel Feygin [mailto:feygin@unitspace.com] > Sent: Freitag, 22. November 2002 11:21 > To: uddi-spec@lists.oasis-open.org > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 > Subscription API > > > Version 1.01 enclosed with minor formatting changes. > > > > -----Original Message----- > > From: Daniel Feygin [mailto:feygin@unitspace.com] > > Sent: Thursday, November 21, 2002 8:31 PM > > To: uddi-spec@lists.oasis-open.org; Tom Bellwood > > Cc: 'Von Riegen, Claus'; 'Wai-Kwong Sam LEE' > > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 > > Subscription API > > > > > > Please find the change request attached to this message. > > > > Daniel > > > > > > > -----Original Message----- > > > From: Tom Bellwood [mailto:bellwood@us.ibm.com] > > > Sent: Wednesday, November 20, 2002 11:45 PM > > > To: uddi-spec@lists.oasis-open.org > > > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 > > > Subscription API > > > > > > > > > > > > > > > > > > > > > Daniel, > > > > > > Your prior note on this got lost in the vast sea that is my email > > > inbox. > > > Sorry. You make a good suggestion. The reasons for > > > subscriptionResultsList not being modeled as you suggest are > > > simple and historical. When we started out with > > > subscription, we had allowed an unbounded cardinality on > > > subscriptionFilter. After some debate, this was later > > > changed to keep things simpler and more managable for > > > providers. The subscriptionResultsList was not changed since > > > it was still correct even with the limitation on > > > subscriptionFilter. Making the change you suggest would > > > tighten things up just a bit more though, so it is an errata > > > worth considering. > > > > > > Thanks, > > > Tom Bellwood Phone: (512) 838-9957 (external); TL: > > 678/9957 > > > (internal) > > > Co-Chair, OASIS UDDI Specification TC > > > > > > > > > > > > To: uddi-spec@lists.oasis-open.org > > > cc: "'Von Riegen, Claus'" <claus.von.riegen@sap.com>, > > > "'Wai-Kwong Sam > > > LEE'" <Sam.Lee@oracle.com> > > > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI > > > V3 Subscription > > > API > > > > > > > > > > > > Here is the updated schema definition: > > > <xsd:complexType name="subscriptionResultsList" > > final="restriction"> > > > <xsd:sequence> > > > <xsd:element ref="uddi_sub:chunkToken" > > > minOccurs="0"/> > > > <xsd:element ref="uddi_sub:coveragePeriod"/> > > > <xsd:element ref="uddi_sub:subscription"/> > > > <xsd:choice> > > > <xsd:element ref="uddi:bindingDetail"/> > > > <xsd:element ref="uddi:businessDetail"/> > > > <xsd:element ref="uddi:serviceDetail"/> > > > <xsd:element ref="uddi:tModelDetail"/> > > > <xsd:element ref="uddi:businessList"/> > > > <xsd:element > > > ref="uddi:relatedBusinessesList"/> > > > <xsd:element ref="uddi:serviceList"/> > > > <xsd:element ref="uddi:tModelList"/> > > > <xsd:element > > > ref="uddi:assertionStatusReport"/> > > > </xsd:choice> > > > <xsd:element ref="uddi_sub:keyBag" minOccurs="0" > > > maxOccurs="unbounded"/> > > > </xsd:sequence> > > > <xsd:attribute name="someResultsUnavailable" > > > type="xsd:boolean" use="optional"/> </xsd:complexType> > > > > > > A question I asked in an earlier email was whether this had been > > > considered and was rejected due to lack of tool support. > Would all > > > major schema processors/WSDL compilers interpret this > correctly and > > > produce the expected code? > > > > > > Daniel > > > > > > > > > > -----Original Message----- > > > > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com] > > > > Sent: Wednesday, November 20, 2002 5:39 PM > > > > To: 'Wai-Kwong Sam LEE' > > > > Cc: 'Daniel Feygin'; uddi-spec@lists.oasis-open.org; Tom > > > Bellwood; Luc > > > > Cl?ment > > > > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 > > > > Subscription A PI > > > > > > > > > > > > Yes, that's why I said "the return structures within the > > > > subscriptionResultList could be modeled as a choice". The > > > other child > > > > elements within the subscriptionResultList can appear in > > > parallel, as > > > > you outlined below. > > > > > > > > Claus > > > > > > > > -----Original Message----- > > > > From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com] > > > > Sent: Mittwoch, 20. November 2002 15:34 > > > > To: Von Riegen, Claus > > > > Cc: 'Daniel Feygin'; uddi-spec@lists.oasis-open.org; Tom > > > Bellwood; Luc > > > > Cl?ment > > > > Subject: Re: [uddi-spec] subscriptionResultsList in UDDI V3 > > > > Subscription A PI > > > > > > > > > > > > The observation is *almost* correct but not quite: > > > > > > > > subscriptionResultList can contain at most two elements > because in > > > > some cases, it needs to report deleted / "virtual" deleted > > > entities, > > > > in addition to entities that have been added/updated, e.g., > > > > > > > > <uddi_sub:subscriptionResultList> > > > > ... > > > > <uddi:businessList> > > > > <!-- businesses that have been inserted/updated -->... > > > > </uddi:businessList> > > > > <uddi_sub:keyBag deleted="true"> > > > > <!-- businesses that have been deleted / "virtual" > > > deleted -->... > > > > </uddi_sub:keyBag> > > > > > > > > </uddi_sub:subscriptionResultList> > > > > > > > > > > > > > > > > - sam > > > > > > > > Von Riegen, Claus wrote: > > > > > Daniel, > > > > > > > > > > Your observation is correct. > > > > > The subscriptionResultsList structure can in no way contain > > > > more than > > > > > one Inquiry API return structure. Thus, the return > > > > structures within > > > > > the subscriptionResultList could be modeled as a choice. > > > I support > > > > > your idea to create a change request. During V3 specification > > > > > development, we tried to put as many syntactical > > > constraints in the > > > > > UDDI schemas as possible in order to catch as many errors > > > (both by > > > > > UDDI clients and nodes) as possible during schema validation. > > > > > > > > > > Claus > > > > > > > > > > -----Original Message----- > > > > > From: Daniel Feygin [mailto:feygin@unitspace.com] > > > > > Sent: Mittwoch, 20. November 2002 11:07 > > > > > To: uddi-spec@lists.oasis-open.org > > > > > Cc: Tom Bellwood; Luc Cl?ment > > > > > Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3 > > > > > Subscription API > > > > > > > > > > > > > > > I received no response to my earlier inquiry. If there is no > > > > > reasonable explanation to the apparent discrepancy alluded > > > > to below, I > > > > > think a change request is in order. I will write it, but > > > > the lack of > > > > > acknowledgement of the issue on the part of TC membership > > > makes me > > > > > wonder if I am correct in my assumption that the current V3 > > > > spec and > > > > > schema are sub-optimal in this respect. > > > > > > > > > > Daniel > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > > >>From: Daniel Feygin [mailto:feygin@unitspace.com] > > > > >>Sent: Friday, November 01, 2002 2:13 PM > > > > >>To: uddi-spec@lists.oasis-open.org > > > > >>Subject: [uddi-spec] subscriptionResultsList in UDDI V3 > > > Subscription > > > > >>API > > > > >> > > > > >> > > > > >>I am looking through the V3 Subscription API and cannot > > > explain one > > > > >>thing about it that I don't think has been discussed > > > outside of the > > > > >>UDDI Consortium's Working Group. subscriptionFilter is > > modeled as > > > > >>exactly one of either of the get_xx or find_xx > > > operations, which I > > > > >>find quite fitting. At the same time > subscriptionResultsList is > > > > >>modeled to allow multiple get_xx/find_xx responses per > > > subscription, > > > > >>whereas subscription can only have one subscriptionFilter. > > > > >> > > > > >>Can someone please help me understand why > > subscriptionResultsList > > > > >>does not use the "choice" model the way > > > subscriptionFilter does? Is > > > > >>this related to the lack of adequate development > tools support? > > > > >> > > > > >>Daniel > > >
Attachment:
uddi-spec-tc-cr-subscriptionresults-20021121.doc
Description: MS-Word document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC