Yes, this is one easy way to deal with the issue. Many OGC interface specs
have an optional parameter/flag (whatever you wish to call it) that allows
optional/and-or vendor specific extensions to an interface/payload to meet
specific requirements. If done correctly, then can be properly be validated
and communicated. Also, in terms of ISO definitions for profiles and
application schemas - if done correctly - what we end up having is/are CAP
application schemas. This is very normal best practice in IT when dealing
with XML based standards. Hope this is not too cryptic :-)
Cheers
Carl
----- Original Message -----
From: "Bullard, Claude L (Len)" <>
To: "'Art Botterell'" <>
Cc: "Emergency_Mgt_TC TC" <>
Sent: Friday, June 17, 2005 3:06 PM
Subject: RE: [emergency] Re: Circle and Polygon
> "I haven't heard any actual implementer report any of this as a
> problem... nor have I heard any technical reason why it should one.
> This whole topic seems to be based on a hypothetical concern for some
> third parties' sensitivities."
>
> That speaks for itself.
>
> Renato is asking that legacy systems be supported by a
> system reference flag. It is a reasonable request that
> we honor every day when customizing our systems for
> customers in response to RFPs.
>
> One can add the flag in their own namespace or
> that of the customer. This means of proprietary
> extension is reasonable to use when the normative
> specification offers no support. If a CAP validator
> balks, the validator is wrong.
>
> len
>
>
> From: Art Botterell [mailto:]
>
> On Jun 17, 2005, at 6/17/05 1:00 PM, Bullard, Claude L (Len) wrote:
>> Please respond to the requirement to enable alternative CRSs
>> as needed.
>
> With all due respect, Claude, there's a difference between a
> suggestion and a requirement. The requirements for CAP and for EDXL
> were considered at some length and adopted by this TC... and
> supporting alternate CRSs isn't among them. (And we did go over this
> material at some length back during the CAP 1.0 deliberations.)
>
> And I don't think anyone's credentials have been questioned here.
> We've all seen what happens when issue discussions deteriorate into
> ad-hominem, and I hope and believe that we're all making a special
> effort to stick to the facts and leave opinions and speculation about
> other folks' motives to one side.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
