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

[Daniel Feygin <feygin@unitspace.com>]

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