[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. Ciao, Rex 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) >pembley@ghinternational.com > >-----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; >emergency@lists.oasis-open.org >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, >Rex > > >At 1:39 PM -0500 3/18/05, Paul Embley wrote: >>On September 30, [2003] (incidentally, 10 days after they issued a >statement >>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 >free >>to use. ISO was the only one in question. The statement above solves >that. >>As long as codes from FIPS, ANSI, and ISO that we can FIND (sometimes >that's >>a problem) are used, then there is no cause for concern for the GJXDM. >This >>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) >>pembley@ghinternational.com >> >>-----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, >>somehow. >> >>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. >> >>Ciao, >>Rex >> >>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 >>>lists. >>> >>>Rrepsectfully, >>> >>>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 >>>better. >>> >>>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?). >>>> >>>>Cheers >>>>Kon >>>> >>>> >>>>--------------------------------------------------------------------- >>>>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]