Hi Mark,
On Apr 11, 2006, at 7:24 PM, Mark Nottingham wrote:
If your site chooses to use the semicolon in this fashion,
certainly. However, "standardising" on that would break URI
opacity, as this isn't defined in the generic syntax or in the HTTP
scheme. Existing sites can and do use the semicolon for other
purposes; e.g., matrix URIs.
Right -- that was the original discussion about using HTTP's "Link:"
or HTML's <link rel="properties"> to indicate server-specific
structure. As long as we are sufficiently clear about *what*
structure to use in the URL, so that clients _know_ it is safe to do,
it doesn't actually violate opacity:
http://microformats.org/wiki/rest/opacity
We obviously don't have such a spec yet, but the goal is to figure
out what's needed to create one. Given that ";" is a valid
character, it might make a useful visual for such purposes. Of
course, we'd need to bang on the idea a little more before we know
for sure. I just wanted to make sure we all had a common
understanding of what opacity does (and does not) mean.
-- Ernie P.
Cheers,
On 2006/04/11, at 5:22 PM, Breton Slivka wrote:
rfc2396 briefly mentions in section 3.3:
"The path may consist of a sequence of path segments separated by a
single slash "/" character. Within a path segment, the characters
"/", ";", "=", and "?" are reserved. Each path segment may
include a
sequence of parameters, indicated by the semicolon ";" character.
The parameters are not significant to the parsing of relative
references."
it further mentions
"Extensive testing of current client applications demonstrated that
the majority of deployed systems do not use the ";" character to
indicate trailing parameter information, and that the presence
of a
semicolon in a path segment does not affect the relative
parsing of
that segment. Therefore, parameters have been removed as a
separate
component and may now appear in any path segment. Their influence
has been removed from the algorithm for resolving a relative URI
reference. The resolution examples in Appendix C have been
modified
to reflect this change."
It doesn't seem to go into much more detail about what a
"parameter" is, so I will assume for now (unless someone can find
the relevant documentation on this) that it is up to the specific
application to determine the usage for these paramaters.
THEREFORE, one can use semicolon parameters to retrieve properties
from resources like so
http://www.hostname.com/database/
object;property1;property2;property3/
subobject;property4;property5;property6
it is possible then, to standardize on at least one parameter name
which would return a list of available properties, or simply
return all available properties. Individual properties can be
retrieved using URI scheme as above.
HOW these properties are returned to the client is another matter.
Whether it is through metatags, or header information, I have no
idea which is best. But I thought it would be somewhat useful to
the conversation to throw in that oft forgotten and unused
reserved character in URI naming schemes: The semicolon.
On Apr 11, 2006, at 3:32 PM, Dr. Ernie Prabhakar wrote:
I've always felt there was something wrong with WebDAV, and Roy
did a nice summary of what over on rest-discuss:
On Apr 11, 2006, at 12:40 PM, Roy T. Fielding wrote:
PROP* methods conflict with REST because they prevent
important resources from having URIs and effectively double the
number of methods for no good reason. Both Henrik and I argued
against those methods at the time. It really doesn't matter
how uniform they are because they break other aspects of the
overall model, leading to further complications in versioning
(WebDAV versioning is hopelessly complicated), access control
(WebDAV ACLs are completely wrong for HTTP), and just about every
other extension to WebDAV that has been proposed.
The interesting question for me is what the "right" way to do
properties would be over HTTP. I presume it would require some
sort of convention for a property namespace, which implies non-
opaque URLs. Which in term (in order to be RESTful) would
require the *server* to have some way to tell clients about it,
since clients shouldn't *assume* URI structure.
Any thoughts about the optimal way to do that?
-- Ernie P.
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
