[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]