Major It's occurred to me from time to time that having "extension points" (in the forms of <parameter> and <resource>) has proven very helpful in Info and might also be useful in Alert and Area. As an example, a shapefile, GML or KML file might logically attach to an Area block, as might information about rate and direction of movement. [But note again the event-vs-alert dichotomy... historically we've been vague about that distinction and it's caused a lot of trouble, at least for me.]
Comparable examples for extensions to Alert don't spring to my mind right now but I can't think of any reason they couldn't exist.
Note that the above would require both <parameter> and <resource> options in Area, and potentially also in Alert. We should consider the semantic implications of putting extended content in one block vs another, but I think that's probably manageable and personally I don't see much of a downside.
(Except possibly in the area of back-compatibility. Separately I'll be suggesting that it might make sense to advance BOTH a 1.3 and a 2.0 version of CAP, where 1.3 would protect back-compatibility and 2.0 could offer more fundamental advances. I'm thinking they could compete constructively the way Python 2 and 3 do. I wouldn't have suggested this when CAP adoption was new and delicate, but at this point I think we have more to fear from becoming legacy-bound than from confusing adopters. But again, that will be a separate issue... I mention it here only to suggest that back-compatibility may not necessarily be a show-stopper.)
I have a <parameter> that I use for tracking information. If a client sends me a CAP message for troubleshooting I use that <parameter> to help me go straight to what I need for diagnosing without having to build up a query to find it in the system. This is due to parallel processing and a step wise approach to building CAP files so this parameter cuts through all that, but I digress. Nevertheless, I would welcome this <alert> level <parameter> as a way of not having to repeat across several info blocks (it doesn't change). Even without multiple info blocks, it is something I would welcome.
Yes, I've used <note> in a similar fashion but that doesn't permit namespacing the way a <parameter> would.
Reflecting on Art's comment that "a shapefile, GML or KML file might logically attach to an Area block", let me know if the following scenario is how you think the parameter might be used.
Imagine a river flood where thousands of vertices are necessary to concisely depict the impacted portion of the river basin. Including thousands of vertices in a CAP message doesn't seem practical plus our polygon would have to be under 100 vertices as required by FEMA IPAWS. So, could the parameter be a URL pointing to the full blown GIS file of the actual alert area?
It could, but a <reference> to a GML or shapefile might be more effective.
Can someone elaborate on the reasoning behind this? Thanks.