Preliminary thoughts on a few of Jacob's latest comments

["Art Botterell" <ABott@so.cccounty.us>]

3. A note should be added about potential <valueName> collisions
between those of this profile and what other system developers may
choose to use.

There's a potential for collisions, of course, and that's something we've talked about addressing in 2.0 by using UUIDs for valueNames.  In the meantime, what would such a note say, exactly?

4. Are multiple <eventCode>s with a <valueName> of SAME allowed
in an <info> block?

SAME only provides for one, and this particular value doesn't have any use other than for back-compatibility with SAME, so I can't think of any reason to have more than one.

5. In order to support a number of different exchange partners using
the same message, a <parameter> should be added to allow an alert
issuer to indicate that a particular partner should ignore a message
that would normally be acted upon...

Not sure that would really be wise.  A message originator generally isn't expert on all the implications of that sort of choice... for example, the all-news station that's the EAS primary station might be covering the story already, but what about folks listening to its smooth-jazz sister station?  Or watching cable TV?  The official responsible for issuing an alert may not always have a complete or accurate appreciation of who's carrying what story at that point in time, much less the second- and third-order implications of a manual routing decision.  The message originator is really only authoritative on the subject of the alert content.  Alert routing should be done on the basis of policy, not spur-of-the-moment choices.

6. When alert information is delivered to the public through two
simultaneous methods using one medium, the message should be
synchronized....                                                          For EAS
broadcast content (sound/video) included in a message as a
<resource> there is no accompanying text content element.

This is possibly a bit out of scope for the profile, since it has to do with the rules for how CAP messages are to be transformed into SAME.  The ECIG has already specified how the CAP <description> and <instruction> elements should be transformed into audio and visual formats for EAS.  I really think that's better than us creating duplicative, and thus potentially inconsistent, delivery-system-specific fields.

9. The current requirement to include at least one <geocode> with a
SAME value should be changed to optional. The mandatory use of
geocodes should only be used to support legacy EAS equipment and
should not apply to more capable next-generation systems...

While I agree with the intent, the ECIG has already rejected the idea of requiring each and every endec do the geospatial math to derive the SAME-required conversion to FIPS codes.  Endecs are fairly simple-minded devices, and the manufacturers are quite cost-conscious.  I'd certainly support the idea of requiring a circle or polygon in addition, since those could, at minimum, be pre-computed for the counties represented by the FIPS codes.