[Esip-discovery] conforming with some of Atom's more esoteric rules...

[Doug Newman]

See comments below,

Doug Newman - ECHO Operations Lead
douglas.j.newman at nasa.gov
douglas.newman at vangent.com
Vangent, A General Dynamics Company | NASA | ECS Evolution Development Program
http://earthdata.nasa.gov/echo

Note: I am not a government employee and have no legal authority to obligate any federal, state, or local government to perform any action of payment.

On 7/18/13 3:51 PM, Lynnes, Christopher S. (GSFC-6102) wrote:
> As I was poring through the Atom spec (http://www.ietf.org/rfc/rfc4287.txt), I noticed some rules that we are probably not strictly following.  I am wondering if we want to correct that in the next version of the spec.  For example:
>
> o  atom:entry elements that contain no child atom:content element
>        MUST contain at least one atom:link element with a rel attribute
>        value of "alternate".
*ECHO Open Search is compliant with this as of 10.65. Our alternate link 
is our catalog-rest URL to the ECHO10 metadata corresponding to the 
entry. Our describedBy links are additional metadata links supplied by 
the provider in the source metadata. How useful that interpretation is 
to other OS servers I'm not sure.*
> o  atom:entry elements MUST contain an atom:summary element in either
>        of the following cases:
>        *  the atom:entry contains an atom:content that has a "src"
>           attribute (and is thus empty).
>        *  the atom:entry contains content that is encoded in Base64;
>           i.e., the "type" attribute of atom:content is a MIME media type
>           [MIMEREG], but is not an XML media type [RFC3023], does not
>           begin with "text/", and does not end with "/xml" or "+xml".
*ECHO Open Search is compliant with this in all environments since we 
never use atom:content. We always have an atom:summary element for 
datasets and it is populated by the dataset description. Nothing for 
granules though. I'd rather add summary for granules than introduce the 
content concept. Not sure what that would be though.*
>
> For the first rule, we do not "require" atom:content. If not populated, we need a rel="alternate" entry. The most likely candidate for this, and the one used by OGC, is a metadata file. This would imply that we could provide more flexibility to users if we change the rel type for metadata files to alternate (from describedby). Alternatively, we could standardize on requiring the atom:content element.  However, the benefit of the rel="alternate" solution is that we would be more similar to the OGC spec.
>
> The second rule is more obscure and opaque. Technically if we don't have ANY atom:content, the rule doesn't apply. However, the intent is to ensure that there is something human-readable in there, one way or another.  So to conform to the intent, we might want to require either an atom:content or an atom:summary element, in all cases.
>
> Comments?

*By the way. We found these issues of compliance and others by running 
our feeds through this

http://validator.w3.org/feed/
*
> --
> Dr. Christopher Lynnes     NASA/GSFC, Code 610.2    phone: 301-614-5185
> "Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity." -- C. Mingus
>
>
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.esipfed.org/pipermail/esip-discovery/attachments/20130718/3ebad0cb/attachment.html>