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

From: "Sean Leahy" <[email-masked]>
Date: Wed, 8 Mar 2006 15:22:06 +0000

Jari and Hisham,

I woud suggest changing the requirement to:

".......  Previous XML document in this context refers to the last XML 
document that was delivered to that specific subscription." As Jari said, 
the rest is then an implementation issue.

I think for example, Jari's solution works and the only overhead is the 
extra field 'last sent value' (per trigger) in the watcher's filter rule 
document (the latter doc has to be kept in any case). This field <or an 
equivalent> would be updated every time a doc was sent to the watcher. I 
think I was confused before believing that you need to remember all the 
info from the 'previous XML Document' - you only need to keep the value of 
the last sent value for each trigger. I blame the original requirement for 
confusing me. Why do we need the struck-through text - it only seems to 
confuse.

"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 delivered to that specific subscription before any filter was applied to it."

Regards,
Sean

Jari Urpalainen <[email-masked]>
08/03/2006 13:52

        To:     ext Sean Leahy <[email-masked]>
        cc:     "Hisham Khartabil <hisham.khartabil", [email-masked]
        Subject:        Re: [Simple] Issue with comparisons for triggerring

On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote:
> 
> Hisham Khartabil wrote: 
> 
> "Perhaps rephrasing the sentence to say the following will help you 
> understand why I meant with my response.
> 
> The 'previous XML documen' is "the last XML document that was
> selected 
> for delivery to that specific subscription before any filter was 
> applied to it and where the XML document was subsequently delivered, 
> after filtering, to the subscriber"
> 
> What I'm trying to say is that the filters for triggers are used by 
> comparing the current XML document with the XML document that was
> most 
> recently sent to the subscriber, but before the filters were applied
> to 
> it." 
> 
> Sean Leahy> So "the last XML document that was selected 
> for delivery to that specific subscription before any filter was 
> applied to it" could be where the Status changed from 'A' to 'B' 
> - this did not meet the criterion that  it "was subsequently
> delivered, 
> after filtering, to the subscriber" (because the trigger is from 'A'
> to 'C'). 
> 
> Sean Leahy> So now we have to look further back for the document
> that 
> was the "the next last XML document that was selected 
> for delivery to that specific subscription before any filter was 
> applied to it" - this could be where the Status was marked as 'A'.
> i.e. it is 
> the original document that was sent to the watcher in that case this
> doc meets 
> both the criteria. 
> 
> Sean Leahy>  However, in the case that it also was not sent, we have
> to look 
> further back again. 
> 
> Sean Leahy> Each subscription may have to go back to a different
> original 
> unfiltered document. 
> 
> e.g. Presentity = Fred 
> Document Fred F last sent to Watchers A, G, 
> Document Fred E last sent to WatchersB , H 
> Document Fred D last sent to Watchers C, K, R 
> Document Fred C last sent to Watcher D, P, 
> Document Fred B last sent to Watcher E, M 
> Document Fred A last sent to Watcher F 
> 
> How many versions of Fred's unfiltered presence document do we need to
> keep ? 
> 

Looks like you are proposing 6 ;-). If I were to implement this (which
is btw. quite challenging), I would probably maintain only one document,
and the "trigger state" per watcher could be kept e.g. within the
watchers filter rule document, i.e. it could be e.g. an additional
attribute value within the <changed> element. But this is of course an
implementation issue. So imo keeping this "state information" does not
mean that you have to maintain the full published information.
Definitely this is additional state information to remember but I doubt
that it is not a major issue considering all the other tasks that you
have to implement. Another story is whether the text needs clarification
or not.
br,
Jari

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

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 8 Mar 2006 20:02:59 +0100

This simply will not work.

Imagine I have filter that says: Tell me your mood when your location 
has changed by 10km.

This means 2 things:
- a <what> filter selecting <mood>
- a <trigger> filter for <changed-by> of value 10

Now, the first NOTIFY that comes will have the full state, which means 
I get your mood as well as your location information (call it 1st XML 
document).

mood: happy
location: Example st.

You then move by 10km and I get a second NOTIFY. This time, I only get 
your mood in the 2nd XML document sent to me because the filter is 
applied.

mood: happy

If you look at the 2nd XML document that was sent after filtering, you 
will not see any location information since the <what> part of the 
filter did not select it.

You move by another 2km.  A new NOTIFY needs to be generated (a 3rd XML 
document). What you are suggesting is to compare that with the 2nd XML 
document. This is not possible since the filter took out the location 
information. However, if you look at the 2nd XML document that was 
sent, but before the filter got applied to it, and compare it to the 
3rd XML document before any filters were applied to it, it will be 
possible to apply the trigger filter.

What is delivered to the subscriber is orthogonal to what caused the 
trigger. Therefore you cannot used the post filter xml documents to 
compare for a trigger.

Hisham

On Mar 8, 2006, at 4:22 PM, Sean Leahy wrote:

> document that was delivered to that specific subscription." As Jari 
> said, the rest is then an implementation issue.
>
> I think for example, Jari's solution works and the only overhead is 
> the extra field 'last sent value' (per trigger) in the watcher's 
> filter rule document (the latter doc has to be kept in any case). This 
> field <or an equivalent> would be updated every time a doc was sent to 
> the watcher. I think I was confused before believing that you need to 
> remember all the info from the 'previous XML Document' - you only need 
> to keep the value of the last sent value for each trigger. I blame the 
> original requirement for confusing me. Why do we need the 
> struck-through text - it only seems to confuse.
>
> "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 delivered to that specific subscription before 
> any filter was applied to it."
>
> Regards,
> Sean
>
>
>