Ok, sounds like a "go" to me. I will write a change request.
I was concerned about the choice inside a sequence intermixed with other
elements. Actually, Tom indirectly addressed that question, because I
was simply trying to justify the fact that it wasn't done that way
originally.
Thanks to Claus, Tom and Sam for their contributions.
Daniel
> -----Original Message-----
> From: Von Riegen, Claus [mailto:]
> Sent: Thursday, November 21, 2002 11:00 AM
> To: 'Daniel Feygin';
> Cc: 'Wai-Kwong Sam LEE'
> Subject: RE: [uddi-spec] subscriptionResultsList in UDDI V3
> Subscription API
>
>
> The proposal for the schema update looks good to me.
> I don't know what you mean by "lack of tool support". There
> was no issue with xsd:choice so far.
>
> Claus
>
> -----Original Message-----
> From: Daniel Feygin [mailto:]
> Sent: Mittwoch, 20. November 2002 18:27
> 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
> > >>
> > >>
> > >>----------------------------------------------------------------
> > >>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>
> >
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
