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
> >>
> >>
> >>----------------------------------------------------------------
> >>To subscribe or unsubscribe from this elist use the subscription
> >>manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
