Re: [Simple] Issue with comparisons for triggerring

["Sean Leahy" <Sean.Leahy at marconi.com>]

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 <jari.urpalainen at nokia.com> 08/03/2006 13:52

To:        ext Sean Leahy <Sean.Leahy at marconi.com>         cc:        "Hisham Khartabil <hisham.khartabil", simple at ietf.org         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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple