(by Alexandre Bertails, no review yet)
- 1 Goal
- 2 Use-cases
- 3 Requirements
- 4 When you use a SHOULD without a MUST
- 5 When you open the door to 303
- 6 When you don't require a specific default representation for the WebID Profile
- 7 When you don't require a hash URI for a WebID
- 8 When you prefer your own terms instead of well-defined concepts that you can link to a specification
- WebID MUST define what it means to have an identity on the Web
- referring to an Agent identity
- WebID-based authentication
- WebID-based authorization
- one MUST be able to change one's WebID
- one MUST distinguish a WebID (a simple URI for a Web Resource) from a WebID Profile (the Web Information Resource). This MUST not rely on dereferencing.
- the WebID Profile MUST define a default representation format
- the system MUST take efficiency into account
- the system MUST not introduce any incompatility with LDP, especially for Write operations
When you use a SHOULD without a MUST
Then there is no minimal set of expectations that one can rely on. This makes interoperability much harder if even possible.
When you open the door to 303
- not everybody understands HTTP 303
- it raises plenty of questions in the case of HTTP POST/PUT/DELETE/etc.
- that may be a direct problem with LDP
- you must explicitly describe in the spec how many redirects are acceptable (what is the max number?)
- you introduce a redirect for all dereferenced resources (eg. FOAF ontology)
- cachability is an issue
- bookmarks are an issue
- deployment may be an issue (like with a simple Apache server)
When you don't require a specific default representation for the WebID Profile
Then a client is never sure it will understand what gets sent to it.
When you don't require a hash URI for a WebID
- you cannot make the difference between a WebID and a Web Profile without an HTTP GET
- you face the http-range-14, which requires HTTP 303 (see other issues)
Then people don't listen to you. Especially when you persist.