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

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

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 ?

This depends on the number of subscriptions and the triggers operating on 
each subscription.

Is this the intention ? This seems to introduce a scalability problem.

Note: It is the inclusion of support for  'changed from to' and 'changed 
by' that creates the
<scaleability> problem. Perhaps, support for these particular combinations 
of child elements 
should at least be optional.

Hisham Khartabil wrote:

Yes, but that [the last sent XML document to the subscriber before filtering is
applied-my addition] is the one you need to apply the filter to. I don't 
understand how you can compare 2 xml documents where one is filtered 
and the other is not.

Sean Leahy> I never proposed this. I suggested we either compare 2 
filtered documents together or 2 unfiltered documents together and 
believed
the original requirement was unclear which was the case. It appeared to 
specify on the
one hand that unfiltered documents were compared (thus ignoring the 
operation of the
trigger in the past in determining what was delivered) and on the other 
hand that it was
filtered documents that were compared (taking account of what was 
delivered on each
subscription).

Regards,
Sean

Hisham Khartabil <[email-masked]>
07/03/2006 16:54

        To:     "Sean Leahy" <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: [Simple] Issue with comparisons for triggerring

On Mar 7, 2006, at 10:42 AM, Sean Leahy wrote:

>
> Hisham and others,
>
> Please see in-line comments attached below marked 'Sean March 7':
>
> Regards,
> Sean
>
>
>
> Hisham Khartabil <[email-masked]>
>
> 06/03/2006 16:20
>        
>         To:        "Sean Leahy" <[email-masked]>
>         cc:        [email-masked]
>         Subject:        Re: [Simple] Issue with comparisons for 
> triggerring
>
>
>
>
>  On Mar 6, 2006, at 3:14 PM, Sean Leahy wrote:
>
>  Sean March 6
> > When considering the filtering of preferred information using
>  > 'triggers', the child elements 'changed' ('from', 'to', and/or 
> 'by'),
>  > 'added' or 'removed' refer to a comparison between current and
>  > previous XML documents. The 'previous XML document' is 'the last XML
>  > document that was selected for delivery to that specific 
> subscription
>  > before any filter was applied to it'
>  > [draft-ietf-simple-filter-format-05].
>
>  Hisham March 6
> You are making a false assumption about the above quoted sentence.
>  Nothing in that sentence says that the XML document was not sent.
> But if you misread it that way, then I guess it needs rephrasing.
>
> Sean March 7
> I think my point has been missed or I was not clear enough. I am not
> making an assumption that the XML document was not sent rather I am
> obeying the requirement that the comparison is with the last XML
> document "selected for delivery to that specific subscription before
> any filter was applied to it." This necessarily implies that the
> trigger that determines whether a document is delivered or not is part
> of the filter process that <subsequently> determines it MAY not be 
> sent.

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 March 7
> In particular, in the cases of the examples given previously <below>,
> where the trigger uses the child elements 'changed from to' or
> 'changed by', if there is a value that occurs in practice in between
> the wanted values then the document WILL not be sent precisely because
> of the operation of the trigger itself. The trigger occurs within the
> scope of filtering i.e. after the comparison of XML Documents according
> to the definition in draft-ietf-simple-filter-format-05.
>
> Sean March 7
> In my example, a trigger is 'Status changed from value A to value C'
>  but the Status changes in practice from A to B and then again to C. 
> The
> result is that the document would not be delivered when the Status 
> changes
> from A to B nor when the document changes from B to C. The document 
> that
> is 'selected for delivery to that specific subscription before any 
> filter
> was applied to it' (i.e. before the operation of the trigger within the
> filter for preferred information) never changes from value A to value 
> C.
> It only changes from A to C when it is the filtered documents rather 
> than
> the unfiltered documents that are compared. Thus if it was desired to 
> take
> this into account, the requirement would have to change to:
> "...The 'previous XML document' is 'the last XML document that was 
> selected
> for delivery to that specific subscription AFTER any filter was 
> applied to it'
>
> Sean March 6
>  > This requirement is self-contradictory. Although it implies that
>  > attention is given to specific subscriptions during the comparison
>  > process, it actually (and conversely) supports comparisons of 
> versions
>  > on a per presentity rather than on a per subscriber basis. 
>  Subscriber
>  > specific versions are only created after filtering of the 'raw
>  > presence document'. The trigger that eventually determines whether a
>  > document is delivered on a specific subscription is part of the 
> filter
>  > process that is excluded from the comparison.
>  >
>  > e.g. when a trigger such as 'Status changed from value A to value C'
>  > is specified but the Status changes in practice from value A to 
> value
>  > B and then again to value C. The result is that the document would 
> not
>  > be delivered when the Status changes to value C (the document that 
> was
>  > previously selected for delivery BEFORE any filter [e.g. current
>  > trigger] was applied had the Status value B ). The remedy is for the
>  > watcher to set the trigger appropriate to what is required e.g.
>  > 'Status changed to value C' rather than  'Status changed from value 
> A
>  > to value C'.
>  >
>  > Another example is when a trigger such as 'changed by 2' is used and
>  > the last value of the element / attribute was '6' but the element /
>  > attribute actually changes to '7' then changes again to '8'. The
>  > result is that the document would not be delivered when the value
>  > changes to 8 because it has only changed by 1 with respect to the 
> last
>  > (undelivered) version (the document that was previously selected for
>  > delivery BEFORE any filter [e.g. current trigger] was applied had 
> the
>  > element / attribute value 7 ).
>  >
>  > The results meet the formal requirement and also minimise the
>  > scalability issues that would otherwise be associated with keeping
>  > previous versions of notifications on every subscription that has a
>  > trigger active. However, they may not meet the expectations of
>  > watchers that have interpreted the requirement differently i.e.
>  > stressed "the last XML document that was selected for delivery to 
> that
>  > specific subscription" and ignored the fact that "before any filter
>  > was applied to it" excludes the operation of the trigger itself !
>  >
>  > If the intention (contrary to the stated requirement) is that the
>  > presence server must retain the last delivered set of information 
> for
>  > every subscription involving filters that include triggers, have the
>  > scalability issues been considered ?
>
>  Hisham March 6
> Why is there a scalability issue? Since you only need to retain a copy
>  of the last sent XML document to the subscriber *before filtering is
>  applied*, my guess is that it will be the same for all it was sent to.
>  You just need to mark it with something that indicates who received 
> it.
>  I don't think that will cause scalability issues.
>
> Sean March 7
> See my previous comment of March 7 (above). In fact, it would be 
> necessary
> to retain a copy of the last sent XML document AFTER filtering for 
> preferred
> information (including triggers) is applied per subscription.

I don't understand why you need the xml document AFTER filtering.

>  This XML
> document would differ between subscriptions that invoked different 
> triggers
> and it is simply not good enough to assume it would be the same for 
> all.
> Marking an unfiltered document to indicate who receives it is 
> inadequate
> because the same unfilterred document can result in many different 
> filtered
> documents that are received by different watchers.

Yes, but that is the one you need to apply the filter to. I don't 
understand how you can compare 2 xml documents where one is filtered 
and the other is not.

Hisham

>
>  Regards,
>  Hisham
>
>
>  >
>  > Note: This problem does not affect  the child elements 'added',
>  > 'removed' or 'changed to', it only affects 'changed from to' and
>  > 'changed by' or to put it another way it is the inclusion of support
>  > for  'changed from to' and 'changed by' that creates the
>  > <scaleability> problem. Perhaps, support for these particular
>  > combinations of child elements should at least be optional
>  > ?_______________________________________________
>  > 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: Jari Urpalainen <[email-masked]>
Date: Wed, 08 Mar 2006 15:52:56 +0200

On Wed, 2006-03-08 at 09:48 +0000, ext Sean Leahy wrote:
> after filtering, to the subscriber" (because the trigger is from 'A'
> to 'C'). 
> 
> 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. 
> 

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

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 8 Mar 2006 15:06:30 +0100

> How many versions of Fred's unfiltered presence document do we need to 

As many as needed where all Fred's active subscribers have been marked 
next to one xml document.

>
> This depends on the number of subscriptions and the triggers operating 
> on each subscription.

Correct

> Is this the intention ? This seems to introduce a scalability problem.

Granted you have to keep copies of a few XML documents, but I doubt it 
will introduce scalability problems. There is only one way to prove me 
wrong however :)

Hisham

>
> Note: It is the inclusion of support for  'changed from to' and 
> 'changed by' that creates the
> combinations of child elements
> the original requirement was unclear which was the case. It appeared 
> to specify on the
> trigger in the past in determining what was delivered) and on the 
> other hand that it was
>  >  > 'triggers', the child elements 'changed' ('from', 'to', and/or
>  > 'by'),
>  >  > 'added' or 'removed' refer to a comparison between current and
>  >  > previous XML documents. The 'previous XML document' is 'the last 
> XML
>  >  > document that was selected for delivery to that specific
>  > subscription
>  >  > before any filter was applied to it'
>  >  > [draft-ietf-simple-filter-format-05].
>  >
>  >  Hisham March 6
>  >  > This requirement is self-contradictory. Although it implies that
>  >  > attention is given to specific subscriptions during the 
> comparison
>  >  > process, it actually (and conversely) supports comparisons of
>  > versions
>  >  > on a per presentity rather than on a per subscriber basis.
>  >  Subscriber
>  >  > specific versions are only created after filtering of the 'raw
>  >  > presence document'. The trigger that eventually determines 
> whether a
>  >  > document is delivered on a specific subscription is part of the
>  > filter
>  >  > process that is excluded from the comparison.
>  >  >
>  >  > e.g. when a trigger such as 'Status changed from value A to 
> value C'
>  >  > is specified but the Status changes in practice from value A to
>  > value
>  >  > B and then again to value C. The result is that the document 
> would
>  > not
>  >  > be delivered when the Status changes to value C (the document 
> that
>  > was
>  >  > previously selected for delivery BEFORE any filter [e.g. current
>  >  > trigger] was applied had the Status value B ). The remedy is for 
> the
>  >  > watcher to set the trigger appropriate to what is required e.g.
>  >  > 'Status changed to value C' rather than  'Status changed from 
> value
>  > A
>  >  > to value C'.
>  >  >
>  >  > Another example is when a trigger such as 'changed by 2' is used 
> and
>  >  > the last value of the element / attribute was '6' but the 
> element /
>  >  > attribute actually changes to '7' then changes again to '8'. The
>  >  > result is that the document would not be delivered when the value
>  >  > changes to 8 because it has only changed by 1 with respect to the
>  > last
>  >  > (undelivered) version (the document that was previously selected 
> for
>  >  > delivery BEFORE any filter [e.g. current trigger] was applied had
>  > the
>  >  > element / attribute value 7 ).
>  >  >
>  >  > The results meet the formal requirement and also minimise the
>  >  > scalability issues that would otherwise be associated with 
> keeping
>  >  > previous versions of notifications on every subscription that 
> has a
>  >  > trigger active. However, they may not meet the expectations of
>  >  > watchers that have interpreted the requirement differently i.e.
>  >  > stressed "the last XML document that was selected for delivery to
>  > that
>  >  > specific subscription" and ignored the fact that "before any 
> filter
>  >  > was applied to it" excludes the operation of the trigger itself !
>  >  >
>  >  > If the intention (contrary to the stated requirement) is that the
>  >  > presence server must retain the last delivered set of information
>  > for
>  >  > every subscription involving filters that include triggers, have 
> the
>  >  > scalability issues been considered ?
>  >
>  >  Hisham March 6
>  >  >
>  >  > Note: This problem does not affect  the child elements 'added',
>  >  > 'removed' or 'changed to', it only affects 'changed from to' and
>  >  > 'changed by' or to put it another way it is the inclusion of 
> support
>  >  > for  'changed from to' and 'changed by' that creates the
> >  > <scaleability> problem. Perhaps, support for these particular
>  >  > combinations of child elements should at least be optional
>  >  > ?_______________________________________________
>  >  > Simple mailing list
>  > > [email-masked]
>  >  > https://www1.ietf.org/mailman/listinfo/simple
>  >
>  >
>  >
>
>
>