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

[Art Botterell <acb@incident.com>]

Ooops... that post was meant for the CAP Working Group list only... 
my mistake cross-posting it here.

- Art


At 10:18 AM -0800 3/7/04, 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.
>
>>	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.
>
>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.
>
>>	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.  Your "ambiguity" point strikes me as well 
>taken, but since the conventions of namespacing are relatively new 
>and best known within the XML community, we left that particular 
>problem over for later refinement.
>
>>	Please consider improving conformance of these element
>>definitions to common patterns of XML usage. Also, please consider
>>clarifying the specification in at least the areas outlined above.
>
>Bob, you obviously have great passion for this and a lot of 
>expertise to offer.  Is there some reason you can't join OASIS and 
>the Emergency Management TC and take part in these detailed 
>discussions directly?
>
>- Art
>
>To unsubscribe from this list, send a post to 
>emergency-comment-unsubscribe@lists.oasis-open.org, or visit 
>http://www.oasis-open.org/mlmanage/.