OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: CAP and attribute-free encodings...


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]