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

[Kon Wilms <kon@datacast.biz>]

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