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

From: "Sean Leahy" <[email-masked]>
Date: Tue, 7 Mar 2006 09:42:20 +0000

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.

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

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: Hisham Khartabil <[email-masked]>
Date: Tue, 7 Mar 2006 17:54:27 +0100

> Hisham Khartabil <[email-masked]>

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.

> for delivery to that specific subscription AFTER any filter was 
> applied to it'
>
> Sean March 6
> information (including triggers) is applied per subscription.

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

>  This XML

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