Reviewing section: Supplying missing Type Index documents

[csarven]

Some clarifications could help:

If one or both of the Type Indexes are missing, an app needing to write to them that doesn't have Write and Control access to the root storage MAY warn the user that their indexes are missing and that they should use a storage management App to fix their profile.

This seems a bit convoluted.

• Why would the app need Control access?
• Why particularly to the root storage?
• Why bother saying MAY? Consider changing this from requirement to Note or advisement as far as application behaviour in the UI (facing the end-user).

If one or both of the Type Index documents are missing and the app does have Write and Control access to the root storage, the app MAY create these documents.

Similar to the above points.

The Public Type Index document SHOULD be publicly readable, writable by the user (or a group delegated by the user), and a pointer to it MUST be placed in the WebID Profile Document.

• Split public-read requirement from user ( or owner) -write.
• Why SHOULD instead of MUST? If it is not MUST public read, what purpose does the Public Type Index serve? Or rather it doesn't serve what it is intended to serve. (Yes, access controls can always change but the point here is about guaranteeing public read.) MUST user (i.e., the create/owner of the public type index document) -write would be a reasonable expectation I think. (Not mutually exclusive to anyone else having write.)

The Private Type Index SHOULD be readable and writeable only by the WebID owner and a pointer to it MUST be placed in the Preferences Document.

Similar to above points. MUST owner-read and user/owner-write private type index document. (Not mutually exclusive to anyone else having read/write.)

If the Type Index files are created but the pointer to them are not stored, the risk is that new resource get created, leading to confusion and possible loss of data.

Paraphrase as an advisement.