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

[Pedro Gonçalves]

the usefulness of an atom:content @type="html" or "xhtml" is that "normal" clients like gmaps, bing and atom feed readers can still show something even if they don't understand the actual meaning of the entry

I think we should recommend that atom:content is used to give some guidance on how to access or download the data

some examples: 
 
https://maps.google.com/?q=http://eo-virtual-archive4.esa.int/search/ASA_IM__0P/atom/?startIndex=0%26start=2010-01-01%26stop=2010-12-31%26bbox=125,39.9,132.7,43.5

https://maps.google.com/?q=https://dl.dropbox.com/u/63073064/ows/examples/imarine.xml

  

On Jul 18, 2013, at 9:51 PM, "Lynnes, Christopher S. (GSFC-6102)" <christopher.s.lynnes at nasa.gov> 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".
> 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".
> 
> 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?
> --
> 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