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] | [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