[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Updated CAP (v. 0.8a) DOM and Dictionary
Friends - Per our conversation on Tuesday and various personal communications, the attached combines the updated CAP alert message document object model with the newly 11179-ized data dictionary, all for your review. It may not show on a printout, but on the screen you'll see that I've highlighted various updates in yellow. Aside from a number of name changes for simplicity's sake, here are a few changes you might find worth reviewing and discussing: In the <alert> structure: * The message distribution scope element (<scope>) has been redesignated as optional with a default of "Public". [Didn't seem this one would be used often enough to justify making it mandatory.] * For cases where explicit addressing is required, the format for listing multiple addresses (in <address>) is specified. * The handling code (<code>) element now may have multiple occurrences, and a note is added to delineate its uses. In the <info> structure: * The event category (<category>) may now have multiple instances. [Note that we're still reviewing our list of categories; Jerry Weltman has that ball right now.] * I've proposed different labels for the <urgency> categories. [I'm trying to cast all the U/S/C codes as appropriate adjectives, in part so they could be strung together in a sentence and make sense.] The definitions of the categories are unchanged. * Likewise I've proposed different labels for the <certainty> categories. Again, the definitions are unchanged. * The audience-targeting code (<code>) is annotated [to distinguish its use from those of the <scope>, <restriction> and <address> elements.] * The usage of the <web> element (formerly <info_url>) has been expanded [to allow it to point to any textual resource available via a URI.] And in the <area> structure: * After a very interesting discussion with a chap at NWS headquarters who's been experimenting with a CAP application, I've proposed simplifying the rules for this block. [Basically, I'm proposing that any combination of polygons, radii and geocodes be permitted, with the <area> describing the union of all the included elements. The same thing could be accomplished with multiple <area> blocks anyway, so why make things complicated?] * At the same time, I've gently deprecated the use of system- or agency-unique geographic codings (<geocode>) alone without equivalent polygon and radius representations. [Using agency-unique codes means the receiver needs to know that coding scheme (and how many others?), which seems to cut against our goal of interoperability.] I've also appended a couple of implementation notes regarding geospatial representations (thanks to Eliot and the GIS team) and security (thanks to Rick and the Infrastructure team.) And some OASIS legal boilerplate just to make it look like we're serious-minded folks. Obviously all these changes are just proposals and subject to discussion... but I'd encourage you to treat this as a very-nearly-final draft... 'cause we'll need to report something up to the committee level by month's end to keep our TC on schedule. Thanks again for all your hard work and wise inputs. A number of folks are starting to pay attention to what we're doing. We should be proud. - Art
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]