Yes, we should hold off on that, darn
it!
I am copying Camille on this. .EDXL Video can go forward, though.
If you can give this a good going-over, maybe we can schedule an
out-of-calendar, special meeting to review and revote. Seems like
there is quite a bit for Feeds and none for Elements, or am I
mis-scanning this? Can you reply to Jacob and ask if he will be
having any further comments on Elements?
We'll just have to see how it goes, but I would rather not wait
another two weeks. It is always better when we start getting
things done, to keep up the pace for a month or three.
Cheers,
Rex
On 3/5/2013 9:47 AM, Anthony Mancuso wrote:
Hi Rex. Just received these comments from Jacob. Do
we want to hold off on moving the feed doc until I go over
these?
On Mar 5, 2013 7:36 AM, "Jacob Westfall"
< jake@jpw.biz>
wrote:
> Group: Emergency Management Adoption Collateral &
Documents SC
> Folder: Drafts
> Date submitted: 2013-02-21 11:24:07
> Revision: 11
Hi, here are some comments on the CAP feeds draft.
- Page 4 - "The feed <title> should minimally identify
the name of the source" There are no examples of this in the
remainder of the bullet. I also disagree with this as being a
best practice and find its intent confusing. Atom offers an
element specifically designed to identify the creator of an
Alert, <author> and this is what should be used. The
RSS <author> uses an email address only and doesn't work
well.
- Page 5 - "While it is possible (and permissible) to use one
feed" This bullet is confusing. Is the intent to say its
okay to mix entries with different languages in the same feed?
If so, its goes against RSS/Atom best practice guidelines.
Or is the intent to say its okay to mix different languages
in the same entry? If so, it provides no guidance on how to
do this.
- Page 6 - "If possible, when an alert has separate
<info> blocks" This recommendation will result in
numerous duplicate links populating the feed. Since there is
only 1 CAP message, yet multiple entries pointing to that
message, duplicate messages will be retrieved. If feed entry
identifiers are not created properly, it could also result in
duplicate values in the feed and make the resulting feed
invalid RSS/Atom. Further guidance is needed on how to avoid
this.
- Page 6 - "Atom is an evolving technology, while the RSS
specification" This statement in this bullet is incorrect.
RSS was never advanced to a formal standard, unlike Atom, and
Atom has been a stable standard for some time. The guidance
in this section should be very clear. Atom is the preferred
feed format, since it offers a standard that supports all
features needed for CAP support, and RSS while possible, is as
a second choice.
- Page 7 - "entry/id = cap:identifier" CAP <identifier>
values do not make good Entry IDs. Duplicate reasons noted
above, and their format is rarely unique. tagURI's or UUID's
should be the recommended method for Entry IDs.
- Page 7 - "entry/category = cap:category" CAP category
values do not map well to Entry categories without providing a
clearer example of how the scheme and term attributes should
work.
- Page 7 - "entry/summary = cap:headline" CAP headline is
used twice, already for entry/title and there are
recommendations above in the document on how to generate
content for summary.
- Page 7 - "entry/published = cap:sent" There are slight
differences in CAP versus Atom for this format that should be
noted.
- Page 7 - "entry/author/email" The <sender> value from
CAP is not expected to be an email, and if it is, its likely
not meant to be a public facing email address and should not
end up in the feed. <senderName> is anticipated to be
public facing and so its fine to use for entry/author/name.
- Page 7 - "entry/link" A defined mimeType should be provided
in the document to ensure that all feed creators and consumers
know what link actually points to a CAP message. If there are
different mimeTypes in use, there is no interoperability on
which link to use.
- Page 8 - "entry/content" You cannot include just portions
of the CAP alert, that would make the alert XML invalid. This
method should not have the recommendations present in this
draft. When you "inline" the CAP XML, the resulting feed is
quite bloated and it reduces the ability of feed consumers to
filter. They are getting the whole CAP message anyways,
whereas with only a link, they can filter before reaching out
to get the CAP message via a link. This method is really only
good for clients on a streaming connection, or for archival
purposes.
- Page 8 - "Embedding CAP elements" None of these
recommendations are good XML practice. The biggest concern is
that most of the elements shown here are sub-elements of an
info block. So for instance mapping <cap:event> doesn't
work. Its really <cap:info:event> ... Including a
significant portion of the CAP message, as recommended here
with the practice of embedding the entire area block(s), just
results in duplication and bloating of the message, similar to
embedding "entry/content". This practice by the NWS is
strictly geared to their use of XSLT for presentation and
while its their perogative to create their feeds this way,
this shouldn't be encouraged as a best practice.
- Page 9 - "<copyright>, <docs>, and
<image>" There is no need to recommend CAP feeds use
these obscure RSS elements.
- Page 9 - "item/guid = cap:identifier" Using the identifier
will not provide a suitable <guid>. See example
guidance above on Atom <id>'s Further guidance should
also be provided in this document that <id>'s for the
same CAP message should align between different feeds if both
Atom and RSS are provided.
- Page 9 - "item/pubDate = cap:sent" There are important
differences in the CAP versus RSS time formats that should be
noted.
- Page 9 - "item/link" <link> can't be used like it can
be in Atom. <enclosure> is a much better element to use
in RSS as you can specify the mimeType.
- Page 9 - "Embedding CAP elements" This practice should be
discouraged for RSS, its only suitable with Atom.
- Page 11 - "Note: Generally, it's not a good idea to embed
HTML" I'd suggest removing this note as it doesn't really
have any bearing on feed generators.
- Page 11 - "Include multilingual content in one CAP alert
message" There are no guidelines for what to do with the feed
entry itself for this bullet point, unlike 2 and 3 which do
outline guidelines.
- Page 11 - "Any changes to an alert should be reflected as a
new RSS item" Whenever a CAP alert is changed, you have to
issue a new Alert. So this bullet isn't clear on that. There
is a whole new XML file to link to because of this.
- Page 11 - "It is good practice to remove an alert from the
feed once" This bullet directly contradicts the Note that
comes after it.
- Page 12 - Feed Examples - The Environment Canada feed is
actually from NAADS and while it contains EC CAP alerts, EC
has nothing to do with actually generating the feed itself.
-- Some Good Practices Missing from Document --
- Feed servers should support "Conditional GET" and Feed
clients should obey and use these HTTP values in order to
significantly reduce polling bandwidth
- Proper use of GeoRSS elements. To be valid GeoRSS, a single
geometry is allowed. Faced with an Alert with multiple area
blocks or polygons/geocodes, how should a Feed generator
handle this? There are several options, easiest is to create
a centroid or other representative point for the entire alert.
Points are the best supported GeoRSS element and should
properly appear on most maps. Or create a summary polygon
that surrounds the entire alert area, to properly encompass
the alert's area.
--
Jacob Westfall <jake@jpw.biz>
--
Rex Brooks
GeoAddress:
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670
|