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

From: "Sean Leahy" <[email-masked]>
Date: Thu, 9 Mar 2006 12:02:54 +0000

Please see my comments Sean 09/03/06 

Hisham Khartabil <[email-masked]>
08/03/2006 19:02

        To:     "Sean Leahy" <[email-masked]>
        cc:     [email-masked], "Jari Urpalainen <jari.urpalainen"
        Subject:        Re: [Simple] Issue with comparisons for triggerring

This simply will not work.

Sean 09/03/06 O.K. but all we have to do is replace 'last sent value' with 'last 
triggering value' to take account of the case that the trigger operates on 
a different element to the 'included' element.

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

Sean 09/03/06 Note: This could have been "Tell me your mood AND LOCATION when your 
location 
has changed by 10km" but it is not.

Hisham wrote 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.

Sean 09/03/06 Agreed but that is because the watcher explicitly excluded it.
Surely the the watcher could have asked for:

- a <what> filter selecting <mood> and <location>
- a <trigger> filter for <location> <changed-by> of value 10

Hisham wrote 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.

Sean 09/03/06 No I do not think Jari or I suggested the comparison you describe.
The latest xml document is always selected as the raw data (no point in 
using
out of date info). Then when the filtering is done we look at what was the 

'last triggering value'.

The result in your example is first the full state got delivered:

mood: happy
location: Example st.

(and the location value of 'Example st' is stored as the 'last triggering 
value' 
in the local copy of the watcher's filter rule document)

Next the following got delivered:

either:

mood: happy
location: Example st + 10km 
(if location is desired i.e. 'included' in the flter).

or just:
mood: happy (if location not desired)

(In either case the location value of 'Example st + 10 km' is stored as 
the 
'last triggering value' in the local copy of the watcher's filter rule 
document)

Next 

mood: happy
location: Example st + 12km 
is originally selected but then not delivered because the filtering 
determines
that 12km - 10km does not meet the criterion for sending it (<changed-by> 
of value 10).

Hisham 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.

Sean 09/03/06 As I have tried to demonstrate all we have to do is replace 'last sent 
value' with 'last triggering value' to take account of the case that the 
trigger operates on a different element to the 'included' element.
Both elements are always in the raw document it is just necessary to 
examine the triggers as the first part of filtering (before any elements 
used for triggering can get filtered out).

Are we not at risk of going down too much into implementation detail with 
this discussion now ?

Sean

Hisham

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

>
> 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: Jari Urpalainen <[email-masked]>
Date: Fri, 10 Mar 2006 10:55:55 +0200

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
---------------
A     | notify (initial subscription)
B     | -
C     | notify
B     | -
C     | -
A     | -
C     | notify
---------------

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