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

[Kon Wilms <kon@datacast.biz>]

On Mon, 2005-03-07 at 16:18 -0500, Art Botterell wrote:
> At 12:43 PM -0800 3/7/05, Kon Wilms wrote:
> >It makes quite a big difference in terms of keeping things modular vs.
> >static, as I laid it out.
> 
> I'm sorry, but this really sounds to me like an implementation issue 
> trying to push its way up to the standards level.  After all, the 
> point of having a standard is to impose a degree of static-ness in 
> the service of interoperability.

This comes as a result of seeing the addition of CBRN as a new category.
I wish I could say I was in cohorts with whoever (Dave?) is introducing
this field, but I am not. I merely see an inefficiency and am attempting
to rectify it.

As for staticness - that's not a pre-requisite for a standard, and never
will be (how would a lookup be any less static?).

I've asked a number of times in this thread for clarification as to why
such a method would not be a good idea - all I've received has been what
seems like an unwillingness to listen.

> And these enumerations very specifically AREN'T modular.  They're a 
> normative part of the specification and no more mutable than any 
> other part.  A document that has a non-standard value in one of the 
> enumerated fields isn't a valid CAP document.  So I'm not seeing why 
> we wouldn't leave the enumeration in the schema where a validator can 
> enforce it if the implementer chooses.

Ok, so the best option right now (and for the foreseeable future) is to
'file under category Other and attempt to get your field included in the
spec'. If it isn't, you use a different standard, or just run
out-of-spec with the implication that you may break people's parsers.

However, with a lookup table in place people like Dave would be able to
make use of their CBRN category immediately without being out of spec.
People who did not understand his category would be able to parse it
(due to the nature of doing a lookup), without being out of spec. If
Dave feels he needs to interoperate, he submits his field for inclusion
in the next revision of the spec. In effect changes are slipstreamed.

However, using the current categorization naming method, if Dave
implements his new field, he breaks other parsers and he himself is out
of spec. He has to come to the table, make a submission, and wait 6 or
however many months until his field gets into the CAP schema for the
next revision. At that time all other prior implementations lacking said
field are now broken and themselves need to be updated just to parse the
basic message. I call this inflexible.

What happens to all the parsers if someone decides for 1.2 that CBRN
should be broken into Chemical, Biological, Radiological, and Nuclear?

As for a validator 'enforcing' something - what does validating form
have to do with parsing contents? Nothing. Those fields still have to be
parsed, no matter the form. Validators cannot be counted on to validate
both with any form of reliability.

I'd also like to note that XML lookup tables are used fairly widely out
in the wild (although more with database<>field mapping), and that this
approach would have other benefits as well (such as multi-lingual
support without breaking the spec / requiring changes).

Cheers
Kon