Fwd: [CAP] Re: [emergency-comment] Re: CAP and attribute-freeencodings...

[Art Botterell <acb@incident.com>]

Friends -

While I've maintained a relationship with the pre-existing community 
that laid the groundwork for CAP, I've made a concerted effort not to 
drag internal TC disagreements out into that public forum, and to 
express only my understanding of the TC's conclusions and in 
appropriately tentative and open-ended terms.

But for our Chair to publicly criticize our approved Committee Draft 
(see below)... saying things like "we did the wrong thing by taking 
the all attribute approach" and "there is not enough 'specification' 
there to do that in a way that supports the vary nature of what CAP 
is suppose to support"... and to say these things "ex officio," 
explicitly signing himself as TC Chair... and to do it right in the 
middle of a ballot period and immediately prior to the public launch 
of CAP should that ballot pass... all that strikes me as as a 
shocking failure of judgement and leadership, as potentially damaging 
both to the CAP effort and to OASIS's credibility, and as just plain 
wrong.

Allen, I really think you ought to consider whether it might be time 
for you to assume a different role.

- Art


>From: "R. Allen Wyke" <awyke@blue292.com>
>To: cap-list@incident.com
>Subject: [CAP] Re: [emergency-comment] Re: CAP and attribute-free encodings...
>Date: Tue, 23 Mar 2004 11:05:32 -0500
>
>On Mar 7, 2004, at 1:18 PM, Art Botterell wrote:
>
>>At 7:48 PM -0500 3/6/04, Bob Wyman wrote:
>>>I think it would be useful to at least provide some hints as to what
>>>concerns were expressed about the use of attributes. It seems odd that
>>>an XML based format would discard such an important part of XML.
>>
>>Well, I'm not sure what makes attributes an especially "important" 
>>part of XML... certainly they seem to have been the subject of a 
>>long-running and somewhat religious debate within the XML 
>>community. Our own discussion ranged over several issues, not all 
>>of which I entirely followed, including the relative complexity of 
>>parsing attributes in lightweight implementations.
>>
>>The resolution was that since there didn't appear to be anything 
>>that could be done with attributes that couldn't be done with 
>>nested elements, and since the reverse didn't appear to be true, 
>>we'd stick with the "simple XML" approach until something forced us 
>>to use attributes.  However, we didn't take any sort of long-term 
>>position against their use should it became necessary.
>
>Actually, that is not true. Basically the group (EM TC that is) 
>said, "leave well enough alone" and never took the time to 
>thoroughly debate and review. After Jerry asked me about it, I 
>brought it full front to the TC to discuss. Those interested can 
>read the thread here:
>
>http://lists.oasis-open.org/archives/emergency/200305/msg00005.html
>
>Problem is, not even including all the issues that Bob has raised, 
>is that an all element approach provides little in terms of 
>conveying "implied relationships." As a quick example, look at the 
>following:
>
><thing>
>   <thingaboutthing>X</thinkaboutthing>
>   <anotherthingaboutthing>Y</anotherthinkaboutthing>
></thing>
>
>From this all you know is that both <thingaboutthing> and 
><anotherthingaboutthing> are about <thing>. Not understanding of 
>"what" their real relationship is. Now, look at doing it this way:
>
><thing thingaboutthing="X">
>   <anotherthingaboutthing>Y</anotherthinkaboutthing>
></thing>
>
>This takes on a whole new meaning. It is now clear that 
>thingaboutthing is really metadata about the <thing> element, and 
>that it supports all the things about that element. You are able to 
>easily understand its relationship to <thing> as well as to 
><anotherthingaboutthing>.
>
>IMHO, we did the wrong thing by taking the all attribute approach.
>
>>>	In any case, the method used in CAP (i.e. name/value pairs) is
>>>*NOT* the correct way to avoid using XML attributes.
>>
>>Within a pure XML context that's true.  However, the elements where 
>>this approach is used are ones intended to permit the inclusion of 
>>application-specific codes that aren't essential to the function of 
>>CAP and that, for the most part, we have no way of foreseeing at 
>>standards-setting-time.
>
>Correct, but from a technical standards perspective, that is not how 
>you handle that situation.
>
>>So although they're encapsulated within an XML document, they need 
>>to be considered as somewhat apart from the CAP specification and 
>>the XML parsing process, to be treated in the underlying 
>>application that may or may not be XML-based.  Note that we did not 
>>exclude the possibility of importing application-specific tags, 
>>with or without attributes, from a separate namespace, in cases 
>>where such tags are available.
>
>Ok, that is bad. It is bad because it means the information is now 
>meaningless - except for those who just so happen to write code to 
>look for it. Its like searching the web - "if" you find X, then I am 
>interested. It turns most CAP alerts into noise with no way to 
>filtering through what you are looking for, and therefore acting on 
>or brokering it in the right way.
>
>>>	Even if the proposal that normal XML practice be followed in
>>>this area is rejected, there are still problems of ambiguity and
>>>under-specification with the existing name/value pair based system.
>>
>>Um... some might argue that "under-specification" is precisely the 
>>point, since these elements exist entirely to ensure backward 
>>compatibility with a broad variety of legacy systems, especially in 
>>public warning systems.
>
>I don't think that is what he means, entirely. I think it refers to 
>the fact that if you are building a commercial system or even 
>considering a system whereby you do not control 100% of the 
>environment (aka the reason for "standards" one could argue), then 
>there is not enough "specification" there to do that in a way that 
>supports the vary nature of what CAP is suppose to support. CAP is 
>to operate in a world of information, crisis, incidents, etc., and 
>as such, it too needs to be "disaster resilient", which is 
>accomplished by providing the tools it needs to provide, properly 
>facilitating the use of identified related tools, and bringing all 
>of this together in clear and non-ambiguous way.
>
>--
>R. Allen Wyke
>Chair, OASIS Emergency Management TC
>emergency-tc@earthlink.net
>_______________________________________________
>CAP-list mailing list
>CAP-list@incident.com
>http://www.incident.com/mailman/listinfo/cap-list
>
>This list is not for announcements, advertising or advocacy of any 
>particular program or product other than the CAP itself.