Subject: RE: [Simple] Issue with comparisons for triggerring

From: <[email-masked]>
Date: Mon, 13 Mar 2006 12:28:29 +0100

> -----Original Message-----
> From: Jari Urpalainen [mailto:[email-masked]]
> Sent: Friday, March 10, 2006 9:56 AM
> To: ext Sean Leahy
> Cc: [email-masked]
> Subject: Re: [Simple] Issue with comparisons for triggerring
> 
> Hisham and Sean!
> 
> For me the current text is eligible enough although there are some
> implicit rules to interpret (and I think I'll understand the
intention,
> but correct me if my example is wrong ...). If this really needs to be
> clarified (which may not be likely given the 48hours state), an
example
> would be worth a xxx of words:
> 
> Given the state can have values A, B or C and a transition from A to C
> is the trigger rule:
> 
>    state | action
>    ---------------
> 1: A     | notify (initial subscription)
> 2: B     | -
> 3: C     | notify
> 4: B     | -
> 5: C     | -
> 6: A     | -
> 7: C     | notify
>    ---------------

I do not completely understand, why the third notification is sent to
the subscriber. draft-ietf-simple-filter-format-05 says:

"The <changed> element is used to identify the XML element or attribute,
from the package specific XML document, whose value MUST change,
compared to the "previous XML document", in order to activate the
trigger and cause the content to be delivered.  Previous XML document in
this context refers to the last XML document that was selected for
delivery to that specific subscription before any filter was applied to
it."

As far as I understand the above cited text, the trigger in step (7) has
to be evaluated accordingly to the second notification (step 3), because
it is the last XML document that was selected for delivery. Thus, if
comparing states from step 3 and step 7, there is no difference (both
are "C"), so the last notification shouldn't be sent. In fact, no
notification would be sent ever unless someone changes the triggering
criteria. Btw, it sounds very strange to me...

> 
> Similar tables could be given with numbers with <by>. But as I said
I'm
> contented with the current text although in general I'll prefer good
> examples over text (lazy implementer ;-)).
> br,
> Jari
> 
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Hisham Khartabil <[email-masked]>
Date: Thu, 16 Mar 2006 21:14:46 +0100

Michal is correct in his observation. The NOTIFY at step 7 should not 
be sent. As far as the subscriber is concerned, the is C (receiving the 
NOTIFY at step 3). There is no new information given to the subscriber 
at step 7 that s/he requested.

Hisham

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 17 Mar 2006 12:28:31 +0200

> at step 7 that s/he requested.

ok, I was afraid that this wasn't unambiguous enough. So now I must
change my mind (after re-reading the format i-d) that the text needs
some clarification, i.e. it should say that the trigger rule is one-shot
only (perhaps I was mislead by correspondence with electronics, e.g.
monostable multivibrator ;-)). But I don't want to argue whether
multi-shot or one-shot behavior is better...

br,
Jari