Edit comment LC-2835 for Linked Data Platform (LDP) Working Group

Quick access to

Previous: LC-2834 Next: LC-2836

Comment LC-2835
Commenter: Tim Berners-Lee <timbl@w3.org>

Resolution status:

4.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level
of functionality which any LDPR allows and which does not require OPTIONS polling?

OPTIONS is expensive: another round trip.

Always avoid an extra round trip if you can.
We need this system to move really fast.
Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users.

Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension
or a POWDER label say). You have to do it for every fresh URI you find.

The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS?

Maybe key headers can be put into the HEAD and GET response.

Maybe the class of resource announced with Link: rel=type
can have a URI which can be looked up itself and cached.
and will give the set of features in a standard way.

Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that
the core functionality is enough for clients to do what they need.
Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: 2835.html,v 1.1 2017/08/11 06:47:14 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org