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

Lynnes, Christopher S. (GSFC-6102) christopher.s.lynnes at nasa.gov
Thu Jul 18 15:51:54 EDT 2013


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




More information about the Esip-discovery mailing list