[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-spec] Question regarding to tracking removed publisher assertionAND relatedBusinessInfo
Hi Zhe, The TC discussed your attached comments today during the FTF. I appreciate your thoughts on this. The only problem is that neither approach addresses the basic yet perhaps non-obvious problem of when both publishers delete their respective publisherAssertions which form a relationship. We'd hear about the first, but not the second in a subscriptionResultsSet unless we add a state to the completionStatus structure indicating both assertions are incomplete. Perhaps the groupo is missing something, but it seems simplest to leave keyBag as it is and add this additional state to completionStatus. Thanks, Tom Bellwood Phone: (512) 838-9957 (external); TL: 678/9957 (internal) Co-Chair, OASIS UDDI Specification TC STSM - Emerging Technologies IBM Corporation "Zhe (Alan) Wu" <Alan.Wu@oracle.com> on 10/29/2003 11:05:54 AM To: "Rogers, Tony" <Tony.Rogers@ca.com> cc: uddi-spec@lists.oasis-open.org Subject: Re: [uddi-spec] Question regarding to tracking removed publisher assertion AND relatedBusinessInfo Hi Tony, I guess you did not go through my whole email :) I admit that the email is pretty long and boring :=) Actually I'm not proposing to add assertion status report in the keyBag. Rather, I am proposing two approaches: 1: add a removed subelement in subscriptionResultList to handle both deleted assertionStatusItem and relatedBusinessInfo (for details please check the bottom part in this email) Briefly, the subelement looks like: <xsd:element name="removed" type="uddi_sub:removed"/> <xsd:complexType name="removed"> <xsd:sequence> <xsd:element ref="uddi_sub:keyBag" minOccurs="0" maxOccurs="unbounded"/> <xsd:choice> <xsd:element ref="uddi:relatedBusinessInfo" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="uddi:assertionStatusItem" minOccurs="0" maxOccurs="unbounded"/> </xsd:choice> </xsd:sequence> </xsd:complexType> 2. add an attribute "removed" to assertionStatusItem and relatedBusinessInfo. This is a somewhat derivied/simplified, in my mind of course, from the solution suggested in Tom's email. I personally like 1) better since it provides a cleaner separation. Thanks, Zhe (Alan) Wu Rogers, Tony wrote: The problem with the key bag is that it is exactly that: a bag of keys. Adding the assertionStatusReport to this is really horrible (especially given that the key bag is used in other places, too). The assertionStatusReport is already returned in the subscriptionResultsList, and it makes sense to modify this slightly rather than mess up the key bag. Moreover, bear in mind that "deleting" an assertion may only delete one end of the assertion, which is a status update - so it seems not unnatural to say that all assertion deletions can be reported by way of status updates. If you are relying on the subscription results to keep your data up to date, this is not a particularly unnatural way to do it. Luc/Tom will have to confirm, but I think it makes sense to make these TWO CRs, one for dealing with the return of the assertionStatusReports, and one dealing with the "broken" filters. Tony -----Original Message----- From: Zhe (Alan) Wu [mailto:Alan.Wu@oracle.com] Sent: Wed 29-Oct-03 7:58 To: Tom Bellwood Cc: Rogers, Tony; Luc Clement; UDDI Spec TC; alan.wu@oracle.com Subject: Re: [uddi-spec] Question regarding to tracking removed publisher assertion for UDDI v3 subscription. Hi Tom/Tony/Luc/TC, I've no problem with writing up a formal CR. (Please tell me the deadline though:) For your proposed solution, I think it is certainly doable. However, how about relatedBusinessInfo (from request of find_relatedBusiness)? To extend your idea, shall we do something similar to uddi:direction? Would it be simpler to just add an additional attribute 'removed' to both <relatedBusinessInfo> and <assertionStatusItem>? One thing I don't like this solution (even the change I just suggested above) is that it will mix new/updated entities with deleted entities in subscriptionResultList. For example, now assertionStatusReport will contain both updated/new assertionStatusItem's, as well as removed ones. In contrast, the original spec has a cleaner separation: new/updated entities are at the top of subscriptionResultList, removed ones are in the keyBag at the bottom (with the exception for the 'brief' mode). Conceptually, would it be easier for end-users to have something like: <subscriptionResultList>... <new_or_updated> ... </new_or_updated> <removed> ... </removed> </subscriptionResultList> As to your first clarification point, I totally agree. For the second one, could you elaborate a bit further, maybe with an example? BTW, do I need to include these two clarifications into the CR? Thanks, Zhe (Alan) Wu Oracle UDDI Server Team Tom Bellwood wrote: Zhe,, This will be in the minutes from the FTF, but we discussed this item today and came up with a somewhat cleaner solution: · Update completionStatus in base schema to include a “status:both_incomplete” (or similarly worded) option · Annotate spec where this is discussed outside of subscription to indicate that use of status:both_incomplete only applies to subscription · Add explanation in subscription text in spec describing how assertionStatusReport in subscriptionResults supports deletion by examining the completionStatus for presence of “status:both_incomplete”. We also need to clarify what is reported in the keyBag when the key which is part of the filter citeria itself is deleted. For example, if a businessKey is deleted and the filter criteria is a find_service for one of the services in that business, do we report back the deleted serviceKey, all of the deleted serviceKeys from that business, or the businessKey, or all of the above? We agreed that the serviceKey in question is the one that should be returned. We also need to add an attribute to the subscriptionResultsList which indicates when a subscriptionFilter criteria is now broken. This can occur if the filter was searching for specific keys which have been deleted. Subsequent use of the filter would no longer be applicable and the subscriber needs to be informed that this has occurred. You got the TODO for writing up a formal CR to this effect. You ok with that? Thanks, Tom Bellwood Phone: (512) 838-9957 (external); TL: 678/9957 (internal) Co-Chair, OASIS UDDI Specification TC STSM - Emerging Technologies IBM Corporation "Zhe (Alan) Wu" <Alan.Wu@oracle.com> on 10/28/2003 10:15:35 AM To: Tom Bellwood/Austin/IBM@IBMUS cc: "Rogers, Tony" <Tony.Rogers@ca.com>, Luc Clement <lclement@windows.microsoft.com>, UDDI Spec TC <uddi-spec@lists.oasis-open.org>Subject: Re: [uddi-spec] Question regarding to tracking removed publisher assertion for UDDI v3 subscription. Hi Tom/Luc, I've read the comments from both of you. I tend to agree more with Tom on that adding assertion or relatedBusinessInfo (for the case of find_relatedBusiness) into keyBag sounds a little bit confusing, even keyBag is renamed. How about removing the <deleted> subelement from keyBag and adding a <removed> element into subscriptionResultsList? That way, keyBag means just a bag of keys, nothing more than that. Whether it specifies a bag of deleted entities or briefed entities depends on its context. If it's a subelement of <removed>, then it specifies a bag of deleted entities. Specifically, in the language of schema (changes are highlighted in colors): <xsd:element name="keyBag" type="uddi_sub:keyBag" final="restriction"/> <xsd:complexType name="keyBag" final="restriction"> <xsd:sequence> <!-- <xsd:element ref="uddi_sub:deleted"/> --> <xsd:choice> <xsd:element ref="uddi:tModelKey" maxOccurs="unbounded"/> <xsd:element ref="uddi:businessKey" maxOccurs="unbounded"/> <xsd:element ref="uddi:serviceKey" maxOccurs="unbounded"/> <xsd:element ref="uddi:bindingKey" maxOccurs="unbounded"/> </xsd:choice> </xsd:sequence> </xsd:complexType> <xsd:element name="subscriptionResultsList" type="uddi_sub:subscriptionResultsList" final="restriction"/> <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 minOccurs="0"> <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:element ref="uddi_sub:removed" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="someResultsUnavailable" type="xsd:boolean" use="optional"/> </xsd:complexType> <xsd:element name="removed" type="uddi_sub:removed"/> <xsd:complexType name="removed"> <xsd:sequence> <xsd:element ref="uddi_sub:keyBag" minOccurs="0" maxOccurs="unbounded"/> <xsd:choice> <xsd:element ref="uddi:relatedBusinessInfo" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="uddi:assertionStatusItem" minOccurs="0" maxOccurs="unbounded"/> </xsd:choice> </xsd:sequence> </xsd:complexType> Zhe (Alan) Wu Oracle UDDI Server
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]