ISSUE-55: explore WebID URI-schema openness

uri-schema-openess

explore WebID URI-schema openness

The WebID protocol should be open to other URL schemas than HTTP/S . Or should it just make sure it does not exclude their future development ? (HTML 1 did not have all the features of HTML4 but it did not exclude HTML4 from happening, or even XML or n3 or json from coming on the scene.)

In any case logically the WebID protocol should require the WebID to be dereferenced using the canonical dereferencing method for the URL Schema. For http this is the HTTP protocol, for https:// the https protocol.

The simplest protocol to add would be FTP. Thinking about ftp or even including it when writing the spec could be a good way to find hardcoded URL schema presuppositions in the docs.

Related notes:

"There is a lot of flexibility and growth to be gained by allowing any sort of URI, not one from a particular scheme, in most circumstances. Similarly, one should not make assumptions about the schemes involved. This is a facet of the particular parameters about how the technology is used. The choice of type URI in a pracical use of a language is an important flexibility point."

As was discussed in the 2013-02-22 call, the *Conceptual* Spec should be based on "dereferenceable URIs", not just HTTP URIs. (SPDY made a difference in Henry's vocal consideration at the time; FTP, LDAP, and other schemes which "Web browsers" transparently handle are also worth remembering.)

The current Functional Spec (WebID-over-TLS) may reasonably be limited to HTTP URIs, as this will make immediate implementation easier for pioneering developers, but won't block future innovation and expanded implementation of the WebID concept.