It = your scheme for using semicolons for a particular purpose, not
the reserved character itself.
Claiming a reserved character for a particular use world-wide breaks
URI opacity, in the same way that the P3P specification says that you
have to place a file at /w3c/p3p.xml breaks URI opacity.
Considering that there are already people that use semicolons for
site-specific purposes (e.g., matrix URIs), standardising (and that's
the important word) on them for accessing properties will cause
collisions.
For example, if you have an exisitng site using WebDAV, and you want
to change it to this convention, you'll have problems if you have
existing resources with semicolons in their URIs.
That's why I suggested that a site-configurable convention would be
more useful.
On 2006/04/11, at 9:14 PM, Breton Slivka wrote:
err, it isn't? if the generic syntax isn't defined in 2396, where
is it defined?
On Apr 11, 2006, at 8:24 PM, Mark Nottingham wrote:
this isn't defined in the generic syntax or in the HTTP scheme.
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
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
