OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1

Thanks, Paul,

While I am not familiar with DOT, (yet), I do understand the basic 
problem with getting folks together to make an actual decision.


At 2:31 PM -0500 3/18/05, Paul Embley wrote:
>I am not the expert on the 1512 spec, but we work very closely with them.
>All the tables they use, and have referred us (GJXDM) to are actually ANSI
>D20 code tables.  We have a couple of projects going directly with DOT, so I
>will find out their perspective on all of this as well.  It may take me
>quite awhile to get the info, as it may actually require some DOT people to
>get together and make a decision.
>Paul S. Embley
>Practitioner Resource Group
>G&H International Services, Inc.
>502.695.7733 (office)
>502.545.0127 (cell)
>502.695.0055 (fax)
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Friday, March 18, 2005 2:22 PM
>To: Paul Embley; 'Rex Brooks'; 'Ham, Gary A'; acb@incident.com;
>Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
>Thanks for the update, Paul,
>That resolves that issue. I don't know how to go about the IEEE 1512
>issue except that the collaborators I am working with have purchased
>it so it is not a problem for that specific project, but since it has
>been adopted by DOT, where it represents an intersection of DOJ and
>DHS, as well as Emergency Management issues across both CAP and EDXL,
>I will just slog along and see if we (my private group) can devise a
>reliable conversion tool which we can then provide to the larger
>community that will effectively turn IEEE 1512 into CAP-ready XML
>Schema. Since that is what we were planning, to do, it may suffice to
>remove the obstacle.
>Needless to say, it would be wonderful if the lurker who suggested we
>simply adopt IEEE 1512 looked into the option of providing it to
>other standards bodies.
>And, of course, yes, this group does still need to decide how it uses
>which code tables.
>Thanks again,
>At 1:39 PM -0500 3/18/05, Paul Embley wrote:
>>On September 30, [2003] (incidentally, 10 days after they issued a
>>about considering charging royalties for use of their codes) ISO issued the
>>following statements concerning "recently publicized misunderstandings of
>>its current practice and intentions regarding its widely used country,
>>currency, and language codes.
>>      * ISO is to continue with its established practice of allowing
>>free-of-charge use of its country, currency, and language codes from,
>>respectively, the ISO 3166, ISO 4217, and ISO 639 standards, in commercial
>>and other applications.
>>      * There is no proposal currently being considered by ISO to impose
>>charges for use of these codes, including on the World Wide Web and in
>>software applications."
>>The rest of the codes we use in GJXDM (including ANSI D20 and FIPS) are
>>to use.  ISO was the only one in question.  The statement above solves
>>As long as codes from FIPS, ANSI, and ISO that we can FIND (sometimes
>>a problem) are used, then there is no cause for concern for the GJXDM.
>>group will need to decide how it uses which code tables.
>>Paul S. Embley
>>Practitioner Resource Group
>>G&H International Services, Inc.
>>502.695.7733 (office)
>>502.545.0127 (cell)
>>502.695.0055 (fax)
>>-----Original Message-----
>>From: Rex Brooks [mailto:rexb@starbourne.com]
>>Sent: Friday, March 18, 2005 9:37 AM
>>To: Ham, Gary A; acb@incident.com; emergency@lists.oasis-open.org
>>Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
>>I don't have any objections to this practice for design. My concerns are:
>>1) Where do we get our external code lists/tables? We already know
>>that there will be more than one single source since CBRN is a
>>category unto itself, as are several GJXDM-proxied/imported
>  >standards/code lists (some of which we need to pay for unless there
>  >is an agreement between standards bodies that provides for sharing
>>these resources of which I happen to be unaware) and  then there is
>>IEEE 1512 which also entails acquiring three (3) standards. We can't
>>refer to black boxes, after all, not if we wish to perform due
>>diligence, and even if it were possible to extend blind trust for our
>>fellow standards bodies, I would dig my heels in on that for my own
>>peace of mind.
>>2) How do we reliably reference these external code lists/tables? I
>>can guarantee that I will recommend against any proxy mechanism that
>>contains the chokepoints I have already identified, and I don't think
>>we really want to incur the network messaging overhead required to
>>convert and validate 1512 alone, notwithstanding the other little
>>black holes into which our parsers and validators can disappear.
>>My points converge on a conclusion I have been coming to for quite a
>>while now as I explored the twists and turns of these various
>>vocabularies. That conclusion is that we need a reliable way to
>>abstract these code lists out of our work and confine the whole
>>distribution element to a slightly higher level of abstraction,
>>Of course, it is the somehow that has me stumped. All I really know
>>at this point is that if we continue attempting to cover details of
>>vocabularies for every constituency in the distribution header, the
>>darn thing is going to be so complicated as to be inoperable period,
>>let alone interoperable.
>>We have neither the time nor the resources to do that, so we might
>>want to focus on how to solicit aid from the other standards bodies
>>and governmental offices to resolve some of these issues so that we
>>can reliably reference these external code lists/tables and harmonise
>>the top level base or core ontology of Event/Incident Types in such a
>>way that the distribution element only needs to include those
>>references while the particular taxonomies for specific
>>incidents/events that belong to those top level types can safely be
>>relegated to the body of the message.
>>This same advice applies to the simultaneous discussion we are having
>>in regard to the area/areaDesc components.
>>At 8:33 AM -0500 3/18/05, Ham, Gary A wrote:
>>>I agree with Mike, assuming that the actual XML messages remain human
>>>readable (with the possible exception of the polygons.)  Encapsulation
>>>of concerns is a good idea, particularly for unstable categorization
>>>Gary A. Ham
>>>Senior Research Scientist
>>>Battelle Memorial Institute
>>>540-288-5611 (office)
>>>703-869-6241 (cell)
>>>"You would be surprised what you can accomplish when you do not care who
>>>gets the credit." - Harry S. Truman
>>>-----Original Message-----
>>>From: Daconta, Michael [mailto:Michael.Daconta@dhs.gov]
>>>Sent: Friday, March 18, 2005 7:11 AM
>>>To: acb@incident.com; emergency@lists.oasis-open.org
>>>Subject: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1
>>>Hi Everyone,
>>>In terms of general principles, you must also weigh the maturity of the
>>>specification and the probability for the code tables needing to be
>>>updated. Due to the broad scope of the distribution element, I believe
>>>the probability for changing the code tables is high. Therefore the
>>>principle of "separation of concerns" would win out (over simplicity)
>>>and make external code tables a better choice. Regards,
>>>- Mike
>>>Sent from my BlackBerry Wireless Handheld
>>>-----Original Message-----
>>>From: Art Botterell <acb@incident.com>
>>>To: emergency@lists.oasis-open.org <emergency@lists.oasis-open.org>
>>>Sent: Fri Mar 18 00:06:51 2005
>>>Subject: Re: [emergency] Groups - EDIT of emergency-CAPv-1.1
>>>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
>>>at this point.  However, if you want to change the spec, all you need
>>>to do is persuade a majority of the TC.
>>>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.
>>>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
>>>But again, flailing me for not agreeing with you isn't just
>>>unpleasant, it's pointless.  Why not let all points of view be heard,
>>>and then let the TC process decide?
>>>- Art
>>>At 12:05 PM -0800 3/17/05, Kon Wilms wrote:
>>>>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?).
>>>>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>>>>For additional commands, e-mail: emergency-help@lists.oasis-open.org
>>>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>>>For additional commands, e-mail: emergency-help@lists.oasis-open.org
>>>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>>>For additional commands, e-mail: emergency-help@lists.oasis-open.org
>>   >
>>>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>>>For additional commands, e-mail: emergency-help@lists.oasis-open.org
>>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]