Re: [emergency-adopt-docs] Re: [emergency] CAP Example Practices Notes Available for Comment Until May 20

[Jacob Westfall <jake@jpw.biz>]

> I believe I addressed all your comments in prior versions. Can you point to
> anything that was not addressed?

The following comments sent Apr 2.


My comments on the latest Elements draft,

- Why is there a reference made to CAP 1.0 and 1.1 in the opening of the document?

- Circles with radius 0.  This document continues to sit on the fence and needs to be clear on whether this Practice is supported or not.  They are allowed by CAP and have been a common method for denoting a “point” that has been used in practice for a number of years.  Usually at the beginning phase of an emergency when the actual affected area may not be yet be determined but the location is at least known.  If they are to be discouraged, then that argument should be persuasive and well developed.

- Need further definition and an example of the practice in section F “means to extend a CAP message”. There are possible misinterpretations of what this is suggesting is possible.

- Usage documentation.  Parameter is not an acceptable location to provide links to documentation.  Why is this even necessary in an actual message?  Is there an expectation that every time someone opens this CAP message it will retrieve the usage documentation and display it as supplemental information alongside the CAP?

- Expires section.  Expires applies to the information and not the alert message.  This should be made clear as its a common misunderstanding.  The recommendations on how to generate a default expires time are all assuming that its “alert based” and not “information based” which is incorrect.

- “Alert Expiration vs Alert Update”.  This statement is contrary to both the specification and all best practices related to composing a message.  I completely disagree with the Practice being advanced here.

- Get rid of the Element Examples section.  There should be an example provided for each Practice in the sections above.


-- 
Jacob Westfall <jake@jpw.biz>