[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Initial thoughts re: [emergency-comment] Comments on CAP V 1.1
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]