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] | [List Home]


Subject: RE: [uddi-spec] Anomaly in get_subscriptionResults


Title: RE: [uddi-spec] Anomaly in get_subscriptionResults
Not included at all? Interesting.
 
When I was trying to answer the question I re-read the spec, and it seemed that an entry which changed is supposed to be included in the results in its current state, but if it was consequently deleted, one cannot report its current state. The spec does not state what to do in this case - that's what I think should be clarified.
 
My belief that it should be clarified is strengthened. After all:
1. my interpretation is that it should be reported as deleted
2. your interpretation is that it should not be reported
 
Sounds like a potentially nasty interop issue.
-----Original Message-----
From: Luc Clement [mailto:luc.clement@systinet.com]
Sent: Tue 13-Sep-05 7:23
To: Rogers, Tony; uddi-spec@lists.oasis-open.org
Cc:
Subject: RE: [uddi-spec] Anomaly in get_subscriptionResults

--- ooops you must think: surely he's lost his mind... I meant to reply
to this email not the notification of postponement of the FTF.

We've interpreted and implemented as follows: the entity deleted on 1May
2005 IS NOT included in a result of get_subscriptionResults over time
period of 1Jan 2004 to 1 Jan 2005.

This is consistent with the intent of the spec. What specifically in the
spec causes you to believe this to be clarified (too lazy to go hunt for
it).

Luc

-----Original Message-----
From: Tony.Rogers@ca.com [mailto:Tony.Rogers@ca.com]
Sent: Thursday, September 08, 2005 21:52
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Anomaly in get_subscriptionResults

I was just asked a question, and I think the answer implies a need for
additional clarification of the spec.

If a user calls the get_subscriptionResults API, specifying a period of,
say, 1 January 2004 to 1 January 2005, and a subscription filter that
matches a particular business entity that changed on 1 July 2004, then
we should return the current state of that business entity - I think
we're all agreed on that. But if that business entity was deleted on 1
May 2005, which is AFTER the requested period, should we return the
business as deleted (in other words, should we include its key in a
delete key bag?)?

As far as I can see, that's what we obliged to do. For contrast,
returning the last state of the business before it was deleted is
misleading, and returning the state of the business as at the end of the
period is explicitly excluded by the spec.

This means that the deleted bag contains not just those entities which
were deleted (real or virtual) during the period specified, but ALSO
those which were deleted (but only REAL deletes, not virtual ones)
since.

Right?

I think we should clarify this in the spec, because it's an anomalous
and perhaps unexpected result.



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