|
Thanks Yu,
Cheers,
RexOn 3/5/2013 11:23 AM, Yu Chen wrote:
Sigh..
I will work with Tony to both incorporate these comments, and
also look at the Elements document a bit more. I hope to get the
revised versions out by later this week.
I'd be happy to schedule something out-of-calendar.
Yu
On Tue, Mar 5, 2013 at 10:29 AM, Rex
Brooks <rex.brooks@ncoic.org>
wrote:
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
--
--
Rex Brooks
GeoAddress:
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670
|