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] CR-010: isReplacedBy tModel


I agree that it's messy. We could say that isReplacedBy has been replaced by
isReplacedByMultiple and encourage everyone to adopt the category rather
than the identifier.

Anne

> -----Original Message-----
> From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> Sent: Wednesday, January 22, 2003 9:56 AM
> To: 'Anne Thomas Manes'; Uddi-Spec
> Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
>
>
> Anne,
>
> If we have two different tModels for nearly the same concept, it
> would complicate the decision for the publisher which tModel to
> use, but would of course help the inquirer to more clearly
> distinguish between the different cases.
>
> So, let us assume three cases.
>
> First, tModel T1 represents a Web service type for which a new
> version is developed and published as tModel T2.
> Assuming that this is a one-to-one relationship (one tModel can
> be found by using the key of one tModel it is replaced with), the
> publisher of tModel T1 should then add an identifierBag to T1
> that contains a keyedReference isReplaceBy / tModelKey T2.
>
> Second, businessEntities B1 and B2 represent businesses that are
> merged to a business, that is published as businessEntity B3.
> This is a many-to-one relationship (many businessEntities can be
> found by using the key of one businessEntity they are replaced
> with), that means the key of B3 is not an identifier, neither for
> B1 nor for B2.
> Should we recommend to use "isReplacedByMultiple" due to this
> reason, that is, the publishers of B1 and B2 each add a
> categoryBag to their businessEntities that contains a
> keyedReference isReplacedByMultiple / businessKey B3?
>
> Third, tModel T1 represents a Web service type for which a new
> version is developed that consists of multiple single Web service
> types that are published as separate tModels, for example, T2 - T4.
> The RosettaNet PIP 3A4 is an example for this, since up to
> version 1.4, it consists of messages that represent a Purchase
> Order Request, a Purchase Order Change, a Purchase Order
> Cancellation, and a Purchase Order Acceptance, whereas it is
> followed by PIP 3A4 2.0 (Purchase Order Request & Purchase
> Order Confirmation), PIP 3A8 1.0 (Purchase Order Change) and PIP
> 3A9 1.0 (Purchase Order Cancellation).
> This is a one-to-many relationship (one businessEntity can be
> found by using one of the keys of many tModels it is replaced
> with), that means the keys of T2, T3 and T4 are identifiers, the
> all "identify" T1.
> Should we recommend to use "isReplacedBy" due to this reason,
> that is, the publisher of T1 adds a categoryBag to A1 that
> contains three keyedReferences isReplacedByMultiple / tModelKey
> T2, isReplacedByMultiple / tModelKey T3, isReplacedByMultiple /
> tModelKey T4?
>
> I fear that I would have problems to explain this to publishers
> so that they make consistent use of the different isReplacedBy tModels.
>
> What do you think?
>
> Claus
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: Mittwoch, 22. Januar 2003 14:25
> To: Von Riegen, Claus; Uddi-Spec
> Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
>
>
> I'm thinking that the better alternative is to create an
> isReplacedByMultiple tModel.
>
> > -----Original Message-----
> > From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> > Sent: Wednesday, January 22, 2003 7:42 AM
> > To: 'Anne Thomas Manes'; Uddi-Spec
> > Subject: RE: [uddi-spec] CR-010: isReplacedBy tModel
> >
> >
> > Anne,
> >
> > Thanks for the well-prepared change request.
> >
> > As you note in section 3 (Impact statement), there is a
> > significant impact for UDDI V2 registries if we make the change
> > for V2 also, especially if the tModel is already used often.
> >
> > However, there is at least a similar impact for UDDI V3
> > registries that also support UDDI V2 APIs: at the time UDDI V3 is
> > implemented, all keyedReferences to the V2 isReplacedBy
> > identifier system within an identifierBag have to be migrated to
> > then occur within a categoryBag. Otherwise, the V2/V3
> > multi-version registry would have to switch between the two
> > personalities of the keyedReference on the fly - and would have
> > to support two personalities of the same tModel for the different
> > UDDI versions as well (note that the key for the isReplacedBy
> > tModel is not changed).
> > But the migration would mean that V2 API call response messages
> > would contain the isReplaceBy tModel as a category system, which
> > is simply wrong per the V2 specification.
> > Thus, I have the dim feeling that we have to change the
> > categorization for the isReplacedBy tModel already in V2 in order
> > to prevent problems that can occur later.
> >
> > An alternative could be to not change the categorization at all ...
> >
> > Thoughts?
> >
> > Claus
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Mittwoch, 22. Januar 2003 00:39
> > To: Uddi-Spec
> > Subject: [uddi-spec] CR-010: isReplacedBy tModel
> >
> >
> >
> >
> > Anne Thomas Manes
> > 617-497-1748 (land)
> > 617-642-3144 (mobile)
> >
> > ----------------------------------------------------------------
> > 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