You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »


The table below is derived from the following document

Fedora API Spec and Delta Document Verification


Issue DescriptionSpec ReferencePriorityDifficultyRelated JIRAsSprintDepends onNotes

Change the PreferInboundReferences URI in Prefer header

from http://fedora.info/definitions/v4/repository#InboundReferences to the one defined in the spec (ie http://fedora.info/definitions/fcrepo#PreferInboundReferences)

3.2.111



HTTP Head does not return the same headers as if the request were a GET3.3





POSTing a LDP-NR does not return correct constrainedBy Link header3.5





MUST return 409 if request's type Link is not resource's current type or subtype thereof, or not in LDP namespace
  • Though the message coming back in the case of an attempt to move from RDFSource to NonRDFSource says "Resource Already Exists" instead of returning a constrained by header
  • Same message is returned trying to move from ldp:Container to an ldp:DirectContainer or ldp:BasicContainer or ldp:Container

MUST change resource's type if request's type Link is a subtype of resource's current type

MUST change resource's interaction model if request's type Link has an LDP interaction model

3.6





Using PATCH it is currently possible to add an rdf:type of ldp:NonRDFSource to an existing ldp:RDFSource. This should not 3.7.1





Replace current Link rel="type" Header with memento specified link (i.e. http://mementoweb.org/ns#OriginalResource) 4.1





The Accept-Datetime header is used to request a past state, exactly as per [RFC7089] section 2.1.1. A successful response must be a 302 (Found) redirect to the appropriate LDPRm4.1.1





If no LDPRm is appropriate to the Accept-Datetime value, an implementation should return a 406 (Unacceptable).4.1.1





The response to a GET request on an LDPRv must include the following headers


4.1.1





LDPm GET

  • An implementation must support GET, as is the case for any LDPR.
  • The headers for GET requests and responses on this resource must conform to [RFC7089] section 2.1. Particularly it should be noted that the relevant TimeGate for an LDPRm is the original versioned LDPRv.
  • In addition, any response to a GET request must include a <http://mementoweb.org/ns#Memento>; rel="type" link in the Link header.
4.2.1

find existing


LPPm OPTIONS

  •  An implementation must support OPTIONS.
  •  A response to an OPTIONS request must include Allow: GET, HEAD, OPTIONS as per [LDP].
  •  An implementation may include Allow: DELETE if clients can remove a version from the version history, as noted in 3.8 HTTP DELETE.
4.2.2





LDPm: PUT, POST, and PATCH must return 405 method not allowed4.2.3-5





LDPm: DELETE

The server is responsible for all behaviors implied by the LDP-containment of the LDPRm.

4.2.6




This is a MAY: Are we planning to implement?

LDPCv : An implementation must support GET, as is the case for any LDPR. Any response to a GET request must include a <http://mementoweb.org/ns#TimeMap>; rel="type" link in the Link header. Currently the <http://fedora.info/definitions/v4/repository#TimeMap> is being used.


4.3.2





LDPCv: Disallow PUT and PATCH4.3.2





LDPCv: HTTP POST:

  • A POST that does not contain a Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, reflecting the state of the LDPRv at the time of the POST. Any request body must be ignored.
  • A Memento-Datetime header should be understood to create a new LDPRm contained by the LDPCv, with the state given in the request body and the datetime given in the Memento-Datetime request header.
4.3.3





LDPCv: DELETE:

Delete of an LDPCv must remove the LDPCv and removing the versioning interaction model from the original LDPRv.

4.3




Are we planning to support?

Vary :

When an LDPCv supports POST, and allows clients to specify a datetime for created URI-Ms, Vary-Post/Vary-Put: Memento-Datetime.

4.4





Server Managed Version Creation4.5.1




Which one do we plan to support? Both?
Client Managed Version Creation4.5.2




?


Replacing Contents from Mementos


Non-normative note: Using the ingest-by-reference mechanism, one can replace the contents of an LDPRvwith that of an LDPRm by providing it's URL as the URL parameter in a Content-Type: message/external-body header. For example, given an LDPRm with URL http://example.org/some/memento, the full header would be 
Content-Type: message/external-body; access-type=URL; expiration=1;
    URL="http://example.org/some/memento"

4.5.3




Do we plan to support this? And if so due to changes in use of "expiration" the spec will likely change.
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.