UserPreferences

PaceAppControlID


Abstract

A method for the client to signal the server whether a entry should have the supplied atom:id preserved, or to have the server control the atom:id (assign new on POST, keep the same id on PUT).

Status

proposed

applies to draft-14

Rationale

Although the likely common case is that APP will be used to create new entries, there does exist the use case of using APP to migrate entries from one service onto another service.

In this latter use case, it is desirable that the original atom:id be preserved for these entries.

This isn't really something we can sweep under the rubric of "the server can do as it wishes" because for a given server implementation you might very well want to cause either effect, all depending on the context known only at the client end. We still need a way for a client to signal their intention.

This also isn't something for which one could simply say "use an extension". Sure, the exact same spec text could be written up in an extension, but it's addressing a problem inherent and fundamental in the ASF and the APP specs. It belongs in the APP spec because atom:id is a very important thing and one of the reasons we like ASF better than other formats.

Proposal

Modify RNG of section 13.1

    namespace app = "http://purl.org/atom/app#"

     appControl =
        element app:control {
        atomCommonAttributes,
        appDraft?
        & appPreserveId?
        & extensionElement
     }
    
     appDraft =
       element app:draft { "yes" | "no" }

     appPreserveId =
       element app:preserve-id { "yes" | "no" }

Modify final paragraph of section 13.1

The app:control element can contain an optional "app:draft"
element as defined below, can contain an optional "app:preserve-id"
element as defined below, and can contain extension elements
as defined in Section 6 of [RFC4287].

Add a new section under section 13.1

13.1.2 The "app:preserve-id" Element

The inclusion of the app:preserve-id element represents a
request by the client to preserve the atom:id supplied
within the atom:entry, and not assign a new atom:id for this
new entry.

Server support is optional and thus the app:preserve-id
element MAY be ignored by the server.

The number of app:preserve-id elements in app:control MUST
be zero or one. The content of an app:preserve-id element
MUST be one of "yes" or "no".

If the element contains "yes" this indicates a client
request that the atom:id supplied within the atom:entry be
the atom:id of the Member Resource, and that the server not
assign a different atom:id for this entry.

If the app:preserve-id element is not present then servers
that support the extension MUST behave as though an
app:preserve-id element containing "no" was sent.

Impacts

Notes

Any suggestions for better names for this element than app:preserve-id? Maybe app:use-client-supplied-id?

The wording of paragraph 3 of section 13.1.2 could really use some help.

Also, not sure yet whether this should only be applicable for POST requests, or whether it could be useful with PUT requests. I've tried to phrase section 13.1.2 to make the default use make sense for both (with POST, absense = assign a new id, with PUT absence = retain the server controlled id)


CategoryProposals