ISSUE-32

Affordances

Informal list of what's not required by the LDP spec that clients might reasonably expect LDP to tell them how to introspect. Note that I intentionally cast what is likely a too-wide net here, by flagging all 2119 keywords aside from MUST for consideration.

Table contents are based on a mid-March snapshot of the spec. While that makes it somewhat stale, the basic issues should not change much so it should be useful to deal with overall approach issues.

I refrained from rendering explicit the following options that exist in many/all cases:

• Remain silent
• Note that HTTP defines how (usually: try it and then look for a specific status code)
• Explicitly declare it as undefined, out of scope, implementation-specific, or similar

Location	Affordance	What spec says today about introspection	What part of HTTP/RDF covers it, if any	Alternatives identified (if not yet spec'd out)
4.1.3	Membership includes both LDPRs and non-LDPRs			Is there a genuine need for a client to introspect this?
4.1.10, 4.7.1	Representations offered: Turtle required, others optional. Might vary based on Method too, e.g. PATCH formats and POST requests.		content negotiation, 406 Not Acceptable
4.1.11, 5.4.2	LDPRs CRUD'ed using methods not defined in LDP; ditto LDPC members		HTTP method definitions, side effects of GET, HEAD
4.1.12	Entity tags may be strong or weak		etags; weak if W/ prefix present
4.3, 4.4, 4.5, 4.7	PUT, PATCH, POST, DELETE supported (LDPRs and LDPCs)	4.6.2 HEAD+Allow	Allow, Options+Allow, 405 Method Not Allowed
4.4.2	Does server require if-match always "SHOULD require if-match + etags to detect collisions"		status code: 304 Not Modified, 412 Precondition Failed, but no obvious way to detect required-ness of conditional requests as a blanket
4.4.6, 4.7.3, 4.3	Create LDPR using PUT, PATCH, POST; the "create" semantic potentially being separate from the method implementation, perhaps by media type (think about binary members)			Could we re-use AtomPub app:accept ?
4.4.7, 4.7.2, 5.4.10	Update LDPR using PUT, PATCH w/o knowing detailed constraints.			What constitutes detailed constraints?
4.5.2	Delete may have side effects		generally true except for GET/HEAD HTTP method definitions, side effects of GET, HEAD
5.2.3/5.2.4	Choice of membership subject	default LDPC's canonical URI, or object of ldp:membershipSubject
5.2.3/5.2.5	Choice of membership predicate	default rdfs:member, or object of ldp:membershipPredicate
5.3.2	Access to LDPC's non-membership triples	try ?non-member-properties, process redirects
5.3.3	LDPC supports client-initiated paging	try ?firstPage, process redirects HEAD and look for Link header in response	HTTP Link header rel=first
5.3.5.1	LDPC server-initiated paging	should 303-redirect	303 See Other
5.3.6.1	which resource is being paged	should have rdf:type=ldp:Page, ldp:pageOf=container's URL
5.3.7	Does LDPC support *ordered* paging, given that it supports paging at all	detectable after the fact(?) via ldp:containerSortPredicates (gap: what subject?)
5.4.3	LDPC supports creation of non-RDF resources? which?			assuming this is based on media type, would be subset of the "representations offered" row.
5.4.5	Does create 201 response include representation	should not	(post 201) should contain an entity which describes the status of the request and refers to the new resource
5.4.7	Create content sniffing	may; should use request's content-type
5.5.1	LDPC PUT, PATCH updates membership	should not (PUT), silent (PATCH)
5.5.2	LDPC PUT, PATCH updates NON-membership	may (PUT), preferred (PATCH)
5.6.x	DELETE LDPC deletes members too?			Look at <LDPC,rdf:type,ldp:xxx> Look at <LDPC,ldp:xxx,?o>