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

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

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>