OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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






Daniel,

Your prior note on this got lost in the vast sea that is my email inbox.
Sorry.   You make a good suggestion.  The reasons for
subscriptionResultsList not being modeled as you suggest are simple and
historical.  When we started out with subscription, we had allowed an
unbounded cardinality on subscriptionFilter.  After some debate, this was
later changed to keep things simpler and more managable for providers.  The
subscriptionResultsList was not changed since it was still correct even
with the limitation on subscriptionFilter.  Making the change you suggest
would tighten things up just a bit more though, so it is an errata worth
considering.

Thanks,
Tom Bellwood       Phone:  (512) 838-9957 (external);   TL:  678/9957
(internal)
Co-Chair, OASIS UDDI Specification TC



To:    uddi-spec@lists.oasis-open.org
cc:    "'Von Riegen, Claus'" <claus.von.riegen@sap.com>, "'Wai-Kwong Sam
       LEE'" <Sam.Lee@oracle.com>
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: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>
>
>


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC