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

[Rex Brooks <rexb@starbourne.com>]

Hi Folks,

I agree with Art on these issues.

Ciao,
Rex

At 10:00 PM 2/28/2005, Art Botterell wrote:
>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
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-help@lists.oasis-open.org
>
>
>
>
>
>Rex Brooks
>President, CEO, Starbourne Communications Design
>Executive Director, Humanmarkup.org, Inc.
>1361-A Addison
>Berkeley, CA 94702
>510-849-2309