Julian Reschke wrote: > On the link element, the "type" attribute's value is an advisory media > type: it is a hint about the type of the representation that is > expected > to be returned when the value of the href attribute is dereferenced. > Note that the type attribute does not override the actual media type > returned with the representation. Link elements MAY have a type > attribute, whose value MUST conform to the syntax of a MIME media type > [MIMEREG]." > > Now the link to MIMEREG (RFC 4288) doesn't really help, because that > document doesn't define the syntax. > > So, finally, the question: does @type allow a media type *plus* > parameters?
See http://www.imc.org/atom-syntax/mail-archive/msg20665.html for the previous discussion of this issue. In my parser & validator, I use the HTTP media-type grammar. When producing Atom documents I use HTTP media-type grammar, but I make sure not to add any gratuitous parameters, whitespace, or unnecessary quoting. I believe that is the only sensible way to handle it, because atom:link/@type should (be able to) match the Content-Type of whatever it is linking to. There are other similar issues too. For example, some parts of various Atom specifications use a comparison function for atom:link/@type that isn't defined. I do the comparison the same way as we do in HTTP (case-insensitive except for quoted values, whitespace normalized, parameter-for-parameter comparisons). Another example is atom:link/@length which doesn't have a normative grammar. I use "DIGIT+" as the grammar in my projects. Regards, Brian
