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

[Elysa Jones <ejones@warningsystems.com>]

Kon,
We are currently in the process in the EDXL working group of addressing the 
structure for the EDXL Distribution Element enumerated types.  I encourage 
you to join in the discussion and provide suggestions so that your opinion 
can be heard by the group.  Our next call isn't until 3/24 but you don't 
have to wait until then.  It would be great if you would start a new list 
discussion with your particular recommendation for the structure of these 
enumerations to prepare us for that call.
Regards,
Elysa

At 12:43 AM 3/18/2005, Kon Wilms wrote:
>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
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-help@lists.oasis-open.org