[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

link relation values; extensions and behaviors



I have some questions about link relations (from Atom format) as well as
the extensions defined by APP.

* First note that in section 4.2.7.2 of the Atom format it states that
"The value of 'rel' describes the meaning of the link, but does not
impose any behavioral requirements on Atom processors."

* If an implementation defines new values for the rel attribute, must
those values be registered with the IANA?  If an Atom processor comes
across a value for rel that it does not recognize MUST it ignore it and
continue processing?

* Now moving over the APP.  APP defines the "edit" link relation which
"specifies that the value of the href attribute is the IRI of an
editable Member Entry... the href IRI can be used to retrieve, update
and delete the Resource..."  Okay, so an Atom client, when seeing an
atom:link with a rel="edit" expose a means to execute a GET&PUT series
or DELETE against the URL indicated in the href.  But the Atom format
specifically states that the value of the rel attribute doesn't say
anything about behavioral requirements on the atom processor.  But it
seems to me the whole point of registering these values is so that we
can agree upon certain behaviors.

* Section 10.1 of the APP spec talks about collection partial lists and
defines values for the link rel attribute of "first", "next", "previous"
and "last" but these are not covered in section 11 - Atom Format Link
Relation Extensions.  Why are they not covered? Because already added to
the registry in part through the work of RFC5005?  See my earlier
questions on whether values must be registered.

Thanks.

Cornelia Davis
EMC