Re: [emergency] Groups - EDIT of emergency-CAPv-1.1

["Daconta, Michael" <Michael.Daconta@dhs.gov>]

Hi Everyone,
In terms of general principles, you must also weigh the maturity of the specification and the probability for the code tables needing to be updated. Due to the broad scope of the distribution element, I believe the probability for changing the code tables is high. Therefore the principle of "separation of concerns" would win out (over simplicity) and make external code tables a better choice.
Regards,
- Mike 
--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: Art Botterell <acb@incident.com>
To: emergency@lists.oasis-open.org <emergency@lists.oasis-open.org>
Sent: Fri Mar 18 00:06:51 2005
Subject: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1

Kon, I don't suppose you expect to win my support by attacking me 
personally... so maybe I'm not clear on what you're trying to achieve 
at this point.  However, if you want to change the spec, all you need 
to do is persuade a majority of the TC.

I have a feeling that underlying this may be some sort of general 
stylistic preference for external tables over enumerations.  If so, 
maybe we ought to discuss that as a general principal, since we use 
enumerations in several places in CAP and in still more in the EDXL 
draft.  If not, maybe you could help me understand by clarifying 
under what circumstances you'd prefer an enumeration to an external 
table and how this circumstance differs from those.

At this point my personal opinion remains that the current 
formulation is a valid use of the enumeration facility within XML and 
the simplest way to express what we mean... and that simpler is 
better.

But again, flailing me for not agreeing with you isn't just 
unpleasant, it's pointless.  Why not let all points of view be heard, 
and then let the TC process decide?

- Art


At 12:05 PM -0800 3/17/05, Kon Wilms wrote:
>On Tue, 2005-03-08 at 10:51 -0800, Art Botterell wrote:
>>  Well, strictly speaking I don't... the burden of persuasion is on the
>>  proponent.  However, I've tried to explain why I don't think this
>>  change is necessary or appropriate at this time.  Whether or not you
>>  consider mine to be a "good" answer is up to you.
>
>You've given a lot of 'no' answers but never any solid reasons.
>
>>  Anyway, now that this has been recast as a 2.0 issue we can consider
>>  it in the context of EDXL and at a more appropriate time.
>
>Ah, the push-off. Which is exactly how this concluded the last time I
>brought it up. Except now we actually have a real-life example. What a
>waste of time.
>
>>  >'Things will not interoperate' doesn't qualify as a valid
>>  >answer (or excuse).
>>
>>  Excuse me?  If interoperability isn't a good answer/excuse, what is
>>  it we're doing here?
>
>See my first comment.
>
>>  Maybe we need to review the purpose of the "category" element: it's
>>  to provide a simple and predictable taxonomy of events that automated
>>  systems can use to select an appropriate response to receipt of a
>>  particular message.  CAP also provides the "event" element to permit
>>  free-form descriptions, but those aren't predictable enough for many
>>  implementions to rely on.
>
>What does a predictable taxonomy of events have to do with a lookup
>table? A lookup table is just a structure for said data, it can't infer
>any level of complexity besides the fact that you have to implement it.
>
>>  >This is right up there with accusing me of using this to push an
>>  >implementation issue to the standards level. What's up with this?
>>
>>  This pattern of casting a professional discussion in personal terms
>>  is one I've seen increasingly in this TC, and I think it's really
>>  regrettable. 
>
>Then stop doing it. Your comments were out of line. I am not paid to be
>on this group and my membership dues are on my own personal dime.
>
>>  No such general equation is suggested.... but your previous note
>>  struck me, at least, as suggesting pretty clearly that anyone would
>>  be able to add values whenever they were ready and that only "if Dave
>>  needs to be interoperable" would such additions be submitted to the
>>  standards process.  If I misunderstood you, I apologize, but if I
>>  have that right then, yes, I believe it could lead to a significant
>>  loss of interoperability.
>
>As it is, there is a loss in interoperability because the spec does not
>currently have a CBRN category. So this is a moot point. At least with
>abstracting these element lists you keep the core clean and keep the
>lists potentially easily extensible without many code-level changes
>being required.
>
>Making a change to a table although still out of spec has much less of
>an impact on parsers (by parsers I mean machine) than does making a
>change to the core schema, because by the nature of implementing a
>parser for tables you are forced to handle these element structures in a
>way that makes it easy to modify if new elements are introduced (as
>opposed to having to handler code at all).
>
>>  Neither.  I'm just not yet persuaded that there's a substantial
>>  problem here in the first place.  And philosophically I'm concerned
>>  about the potential water-muddying consequences of making unnecessary
>>  changes.
>
>If you fail to be convinced then I quite literally give up.
>
>I have already wrappered what I consider 'bad spec' at the code level.
>At least I can deal with new elements now as they are introduced, and
>not have to make any changes to my code. I can't say if this is the same
>about other implementations (but that is their problem, right?).
>
>Cheers
>Kon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: emergency-help@lists.oasis-open.org