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

[Kon Wilms <kon@datacast.biz>]

On Thu, 2005-03-17 at 21:06 -0800, Art Botterell wrote:
> 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 

This little gem of a sub-discussion is fast reaching the point of
absurdity. I have done no such thing.

> 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.

Well, this isn't a stylistic preference, but a basic design pattern. If
I had my druthers I would break out any ordered list of items that are
subject to change at any time (be it for language or other reason) and
separate them from the core message construct. If a element list is
subject to change or expansion, or becoming unwieldy in size
(proportional to the rest of the schema), it should be separated.

And note I'm not suggesting that the *message* be broken up - but that
the parser or generator combine elements to parse or generate the
message. The message itself is still perfectly humanly readable, and
there is no situation where people have to grab a half dozen printout
lists to parse a message manually.

On the topic EDXL I have been more of a lurker - but I have a few random
thoughts and comments.

- The enumerations in the EDXL draft are massive. I would find it hard
to believe that they are definitive lists and are not subject to change,
both in terms of adding new items and changing existing items. 

- Can we expect all personnel to know the difference between Healthcare
and Public Health? How would I a direct data to a Hospital that doesn't
have a Poison Control Center? I suspect the originator of the message
would spend at least 10 minutes attempting to wrap their head around who
to send the data to (and probably get it wrong in the process, because
there are too many variables).

- Enumerations shouldn't have /'s or ()'s if you want them to be parsed
with any form of reliability at the machine level. These are state
machines and add undue complexity to machine parsing. How would I
categorize 'other than AIRTRANS' (should be 'Other than Air Medical
Transportation' for starters, since there is no AIRTRANS in the list)?
This is a NOT applied to all other items, which means if I want to parse
it in code I need a state machine to parse and at least two state
machines to filter for displaying the message. Ofcourse you could ignore
all that and just categorize the messages verbatim, but that doesn't
make for a very intelligent routing machine, does it?

- The eventtype enumerations have issues too. What is the suggested
practice for categorizing data that is marked as 'e.g. smog conditions,
'spare the air', and > *etc.* < ?

- I also note that in many cases the 'scope' of entities is different,
where one categorization may be a specific industry, another is a
nebulous.

- You have mentioned simplicity and I'm all for that, but I see a lot of
unwieldy complexity here. 

- Am I correct to assume that there will be more iterations of these
lists, until they make a little more logical sense?

- Yes I'm quite aware of the argument of 'must be human readable' - but
there is a point where things backfire.

> 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.

Sure I'm for that too - unless these lists are changing (which they seem
to be) or becoming unwieldy. I actually see data abstraction as the
simpler method of implementation, but thats just me.

> unpleasant, it's pointless.  Why not let all points of view be heard, 
> and then let the TC process decide?

This entire thread consists essentially of you attempting to shoot down
whatever I say. Now you want the TC process to decide? Are you out of
blanks, or reloading? :) I don't believe I ever said the TC should do..
what the TC doesn't usually do.

Cheers
Kon