Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07 - OGC Event Patter Markup

["Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>]

Another mail on the same subject. 


I am actually wondering whether a generic approach shouldn't better go for just uploading PL/SQL code instead some XML document. Maybe that would be more flexible.

Maybe someone could, for the fun of it, try to replicate the functionality of the existing specifications in PL/SQL. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 4 Nov 2009 09:06:38 -0500 (EST)
> Von: creed at opengeospatial.org
> An: "James M. Polk" <jmpolk at cisco.com>
> CC: "Hannes Tschofenig" <hannes.tschofenig at gmx.net>, "\'Brian Rosen\'" <br at brianrosen.net>, geopriv at ietf.org
> Betreff: Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07 -      OGC Event Patter Markup

> I believe that months ago I mentioned the work being done in Europe on
> event alerting, filtering, etc. This work is part of a much larger
> European initiative for pan European spatial data infrastructure
> (INSPIRE), Risk and Disaster Management (ORCHESTRA), and Sensors Anywhere
> (SANY).
> 
> Specifically, those communities have defined an event pattern markup
> language that has been submitted to the OGC. From the document forward:
> 
> The patterns and functionality described in this document can be applied
> to create filters that operate on event streams / clouds. Therefore, it
> can be regarded as an enhancement of the OGC Filter Encoding Standard
> (FES). The discussion in this document is related to all services that
> store or process data, because there are lots of events generated or
> received by these services (e.g. whenever a new objects is created /
> inserted at the service). Applying the techniques described in this
> specification to those events enables on-the-fly filtering of data and
> derivation of higher-level information. This work was supported by the
> OSIRIS project. OSIRIS is an Integrated Project (contract number 0033475)
> co-funded by the Information Society and Media DG of the European
> Commission within the RTD activities of the Thematic Priority Information
> Society Technologies.
> 
> The work is Europe is accelerating and the Asian IT community is now also
> involved.
> 
> My reason for bringing this up again is that I am concerned that the
> GeoPRIV community is creating another pattern for location based event
> filtering that is inconsistent with the work  being done in Europe and
> Asia. I should also add that elements used in EML, such as Observations
> and Measurements and Filter, are soon to be ISO International Standards.
> 
> If anyone is interested, the document is here:
> 
> http://portal.opengeospatial.org/files/?artifact_id=29566
> 
> Regards
> 
> Carl
> 
> 
> 
> > Hannes
> >
> > in-line below
> >
> > At 06:29 PM 11/3/2009, Hannes Tschofenig wrote:
> >>Hi James,
> >>
> >>Thanks for your detailed review. I am in the process of updating it and
> >> have
> >>comments here and there.
> >>
> >>Here is one:
> >>
> >>Draft Text:
> >>
> >>--------
> >>
> >><?xml version="1.0" encoding="UTF-8"?>
> >><filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
> >>     <ns-bindings>
> >>         <ns-binding prefix="dyn"
> >>             urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
> >>     </ns-bindings>
> >>     <filter id="123" uri="sip:presentity at example.com">
> >>         <trigger>
> >>             <changed by="3"> [<---James]
> >>               //dyn:speed
> >>             </changed>
> >>         </trigger>
> >>     </filter>
> >></filter-set>
> >>
> >>------
> >>
> >>[James]
> >>
> >>I get the XML,
> >>but I don't see what the speed now is of
> >>the device/target?
> >>What if this device is moving at 200kmph,
> >>where would that be placed in the XML?
> >>Of, is this left for the application at the
> >>subscriber to calculate?
> >>If the latter is true, something needs to be
> >>said about this expectation.
> >>
> >>------
> >>
> >>The filter would not tell you what the current speed is.
> >
> > ok, I get that now (though it isn't exactly stated this way explicitly).
> >
> > Let me pose a scenario for you and see if there is just one NOTIFY or
> > there are many:
> >
> > Alice is the target.  Initially she isn't moving.  her device accepts
> > a subscription with a <changed by="3"> element in it.  She starts to
> > accelerate (linear or not) until se reaches 100mps.  How many NOTIFYs
> are
> > sent?
> >
> > 1 because she crossed the by="3" attribute, or each time she
> > accelerates more than 3mps faster since the last NOTIFY.
> >
> > I'm guessing the latter, but want to be sure.
> >
> > Again, this isn't exactly explicitly stated in the -07 rev.
> >
> > James
> >
> > BTW -- I think Alice sending a NOTIFY every time she accelerates or
> > decelerates by="3" would be useful information, especially in the
> > emergency case.
> >
> > It's toobad we cannot have a "is moving" but less than by="3"
> > indication.  This would tell us it is in a stationary position or
> > not. Again, for a device/inventory tracking application, this would
> > seem like very useful information to have.
> >
> >
> >>The current document only supports 'by' and hence you cannot say
> >> something
> >>like 'tell me when he goes faster than 100kmph'.
> >>
> >>Ciao
> >>Hannes
> >>
> >>_______________________________________________
> >>Geopriv mailing list
> >>Geopriv at ietf.org
> >>https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv at ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
>