RE: [emergency] RE: Profiles - what do we mean by the term?

["Alessandro Triglia" <sandro@oss.com>]

> -----Original Message-----
> From: Ron Lake [mailto:rlake@galdosinc.com] 
> Sent: Wednesday, November 28, 2007 05:46
> To: Art Botterell; emergency@lists.oasis-open.org; 
> creed@opengeospatial.org
> Subject: RE: [emergency] RE: Profiles - what do we mean by the term?
> 
> Hi Art:
> 
> My suggestion that you use GML geometries in CAP allows you 
> to have BOTH points of view.
> 
> You attach the srsName attribute and then (for now) say its 
> value MUST be "urn:x-ogc:def:crs:EPSG:4326".  If you don't 
> change then there is NO ambiguity and everyone uses ONLY this 
> CRS.  


I would rather do it in this way:  

1) in CAP 2.0, attach the srsName attribute;

2) create a very simple profile (not an extension) that says that the
attribute must have the value "urn:x-ogc:def:crs:EPSG:4326".

In this way, the new CAP 2.0 + profile would have exactly the same level of
interoperability as the current CAP 1.1, but those who do not want that
restriction can use either CAP 2.0 alone, or create another similar profile
specifying a different CRS.

Alessandro


> Should someone in a region wish to adapt CAP and use 
> some other values that is their decision.
> 
> Ron
> 
> -----Original Message-----
> From: Art Botterell [mailto:ABott@so.cccounty.us] 
> Sent: November 27, 2007 7:50 PM
> To: emergency@lists.oasis-open.org; creed@opengeospatial.org
> Subject: Re: [emergency] RE: Profiles - what do we mean by the term?
> 
> Yes, what's been suggested of late is an extension rather 
> than a profile.  I'm in favor of profiles, but extensions are 
> notorious for breaking compatibility. 
> 
> Look, if someone could being us a commitment from China that 
> if we'd complicate the spec in this way they'd adopt CAP, I 
> might actually be persuaded it was a worthwhile trade-off.
> 
> But that's not the situation.  What we're
> talking about is doing definite damage to a successful 
> standard, in terms of increased complexity and reduced 
> interoperability, in hopes of gaining unspecified future 
> benefits that are at best speculative and in any event 
> largely symbolic.
> 
> Technical consideratons aside, that strikes me as a pretty 
> naïve way of doing business.
> 
> - Art
>