RE: [uddi-spec] subscriptionResultsList in UDDI V3 Subscription API

[Daniel Feygin <feygin@unitspace.com>]

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