Thanks, Robin,
I should point out that my comment that Paul's message served to
solve this was meant only in reference to the GJXDM in relation to
our specific effort.
This overall topic is overdue for a large scale airing, but we'll
have to wait for an entirely egregious and blatant case before we
take it on. In the meantime, I believe Dr. Covey refers to the kinds
of activities we can successfully engage in at this point in time as
"sharpening the saw." Harvesting comes later, hopefully, if the
juggernaut picks up enough momentum.
Ciao,
Rex
At 3:55 PM -0500 3/18/05, Robin Cover wrote:
>[Paul Embley said]
>
>>> ISO was the only one in question. The statement above solves that.
>
>1. For some, the ISO statement of September 30, 2003 "solved" the
>problem; for others, the ISO statement most certainly did not.
>
>See the "List of questions raised by various groups in connection
>with the ISO announcement of September 30, 2003:
>
>http://xml.coverpages.org/ni2003-09-20-a.html#listOfQuestions
>
>2. Note that the ISO policies with respect to code lists have
>been a perpetual/ongoing problem, for the Unicode Consortium, IETF,
>IAB, and others. See for example the references to "Stability of the
>underlying ISO standards" and "Accessibility of the underlying
>ISO standards for implementers" in the rationale for revising
>IETF RFC 3066, which depends upon ISO 639 and 3166.
>
>http://www.inter-locale.com/ID/why-rfc3066bis.html
>
>- Robin Cover
> ** Speaking as an individual, not as a representative of any corporate
> entity
>
>
>On Fri, 18 Mar 2005, 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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