Re: [emergency-comment] Re: CAP and attribute-free encodings...

[R. Allen Wyke <emergency-tc@earthlink.net>]

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