Please find the change request attached to this message.
Daniel
> -----Original Message-----
> From: Tom Bellwood [mailto:]
> Sent: Wednesday, November 20, 2002 11:45 PM
> To:
> 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:
> cc: "'Von Riegen, Claus'" <>,
> "'Wai-Kwong Sam
> LEE'" <>
> 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:]
> > Sent: Wednesday, November 20, 2002 5:39 PM
> > To: 'Wai-Kwong Sam LEE'
> > Cc: 'Daniel Feygin'; ; 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:]
> > Sent: Mittwoch, 20. November 2002 15:34
> > To: Von Riegen, Claus
> > Cc: 'Daniel Feygin'; ; 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:]
> > > Sent: Mittwoch, 20. November 2002 11:07
> > > To:
> > > 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:]
> > >>Sent: Friday, November 01, 2002 2:13 PM
> > >>To:
> > >>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
