Initial thoughts re: [emergency-comment] Comments on CAP V 1.1

[Art Botterell <acb@incident.com>]

Friends -

A few personal first reactions to Dr. Iannella's comments:

>1) Section 3.2.1 - Page 10 - "alert" row of table
>
>The xmlns attribute referencing the CAP Namespace URI should
>not be a "MUST" as this is not consistent with the XML Namespace rules.
>The CAP Namespace URI can occur on any element before it is actually used.
>If you use CAP with other XML (eg SOAP) you probably would put ALL 
>XML Namespaces
>at the beginning.

It's a good point, and I'd support deleting note (2) for the data 
dictionary entry for "alert".  The namespace URI would still be 
specified in the schema and could be used as per the current spec or 
otherwise as suggested.


>2) Section 3.2.1 - Page 10 - "identifier" and "sender" rows of table
>
>I would strongly urge the use of URI's [1] as the mandatory scheme 
>for identifying
>these entities. For a "number or string" to be unique will require a 
>more formal
>definition. The <identifier> examples in Appendix A do not show any 
>mechanisms for
>being unique.

Heretofore we've delegated responsibility for the uniqueness of the 
identifier element to the message originator.  We've discussed using 
UUIDs for the corresponding field in EDXL, but also talked about some 
sort of originator-sequential numbering scheme.  Since this might be 
a significant implementation change that would touch everybody, and 
since there seems to be some significant difference of opinion about 
the details, I think I'd lean toward leaving "identifer" as-is for 
now, pending a potential integration with EDXL in CAP 2.0.

However, I would support going ahead and specifying "sender" more 
specifically as a URI, since that's common practice already and I'm 
really not aware of a viable alternative for ensuring global 
uniqueness.


>3) Section 3.2.2 - Page 13 - "language" row of table
>
>I would strongly urge the use of xml:lang [2] to indicate the language of
>element content. I would also not support the use of a default value as this
>is not consistent with open internationlisation.

I'd support adding a mandatory xml:lang attribute to the "info" 
element and deleting the "language" element... it would have have the 
same practical effect, but in a more standard fashion and without 
treating any one language as the default.


>4) Section 3.2.2 - Page 15/16 - "eventCode" and "parameter" rows of table
>
>Have you considered using XML as the syntax for the content of these elements?

We have, of course, but we've wanted to avoid what could be endless 
unique extensions that could pose problems for embedded devices 
and/or in broadcast applications.  Nonetheless, I've had some 
conversations with folks at the European Commission's Joint Research 
Center along the same lines recently, and of course we've been 
discussing sensor issues within the TC.

Might we consider starting to migrate "parameter" toward a structure 
with specified elements... e.g, parameterTime, parameterLocation, 
parameterSource, parameterID, parameterType, parameterReliability, 
parameterUnit, parameterValue and maybe an optional "resource" block? 
I'm thinking parameterType and parameterValue could be mandatory to 
parallel the key=value model.  And parameterType could have a 
namespace attribute to permit decentralized management of the key 
values.

We might allow both formulations for now but depreciate the old form. 
I can see some near-term benefits to this, and I think we could put 
together the specifics pretty quickly, but if the details would be 
controversial we might be wiser to defer this till 2.0.


>5) Section 3.2.2 - Page 16 - "contact" row of table
>
>Have you considered using a more structured value for the Contact details
>such as vCard or xNAL [3] ?

This came up earlier and was simply deferred.  We also kicked it 
around during the ICS-201 conversations.   I like the idea of using 
the OASIS xNAL spec for a more detailed contact structure.  Again, my 
only concern would be about not making the 1.1 transition too taxing 
for implementers.  I guess I'd have a mild personal preference for 
holding this over to EDXL/CAP 2.0, but I'd defer to the other 
implementers on that.


Just my initial personal thoughts.

- Art