Re: [earlywarning] Commentson draft-schulzrinne-atoca-requirements-00

Good to hear that CAP 2.0 will include a GML profile. 
What location shapes are going to be supported? We ran into this issue in ECRIT. 

-------- Original-Nachricht --------
> Datum: Tue, 20 Jul 2010 14:33:05 -0600
> Von: "Carl Reed" <creed@opengeospatial.org>
> An: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, trutkowski@netmagic.com
> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" <hannes.tschofenig@nsn.com>, earlywarning@ietf.org
> Betreff: Re: [earlywarning]	Commentson	draft-schulzrinne-atoca-requirements-00

> Correct -
> 
> CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0
> will incorporate a GML profile that will include the same geometry types
> (plus additional ones) as the LO GML Geoshape Application Schema.  The only
> issue is that the OASIS GML "where" profile will use GML 3.2.1 to be
> consistent with the ISO version of GML and the LO Geoshape schema uses GML 3.1.1.
> 
> Cheers
> 
> Carl
> an OASIS CAP contributor
>   ----- Original Message ----- 
>   From: Hannes Tschofenig 
>   To: trutkowski@netmagic.com 
>   Cc: earlywarning@ietf.org ; Tschofenig,Hannes (NSN - FI/Espoo) 
>   Sent: Tuesday, July 20, 2010 12:33 PM
>   Subject: Re: [earlywarning] Commentson
> draft-schulzrinne-atoca-requirements-00
> 
> 
>   Hi Tony, 
> 
>   thanks for pointing to the CAP Implementer's workshop and in particular
> the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP
> Implementations"
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc. 
> 
>   My understanding of that document (and my participation at an earlier
> workshop) is there is room for improvement in the CAP specification from an
> interoperability point of view.
> 
>   Since the work in this group only focuses on the transport of alerts
> rather than the actual content of the alerts we should not be impacted. 
> 
>   Ciao
>   Hannes
> 
>   On 16.07.2010 13:05, Tony Rutkowski wrote: 
>      Hi Martin, 
> 
>     You might also consider the concepts on architecture 
>     and identity constructs that emerged from last year's 
>     global gathering of emergency messaging authorities 
>     convened at the World Meteorological Organization. 
>    
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html 
> 
>     See especially the Draft Implementors Note. 
> 
>     best, 
>     tony 
> 
> 
>       I'm currently unsure about the value of this document.  The
> different components of the document are somewhat disjointed: problem statement,
> architectural model, and requirements don't support each other particularly
> well. 
> 
>       General Comments: 
> 
>       This model presented in this document is highly abstract.  Without a
> more concrete relationship with the requirements, it's hard to understand
> the value of the model.  Section 3 looks too much like a copy-and-paste
> from the email architecture. 
> 
>       A simpler model might be a better starting point: 
>          author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient 
> 
>       Such a model can be evolved to involve relays or mediators by
> overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing
> wrong with giving these entities names and descriptions, but they can form
> part of a second architectural layer. 
> 
> 
> 
>     _______________________________________________ 
>     earlywarning mailing list 
>     earlywarning@ietf.org 
>     https://www.ietf.org/mailman/listinfo/earlywarning 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> 
>   _______________________________________________
>   earlywarning mailing list
>   earlywarning@ietf.org
>   https://www.ietf.org/mailman/listinfo/earlywarning