- From: <Manuel.CARRASCO-BENITEZ@ec.europa.eu>
- Date: Mon, 8 Sep 2014 12:18:20 +0000
- To: <leigh@ldodds.com>
- CC: <adler1@us.ibm.com>, <public-dwbp-wg@w3.org>
Dear Leigh, The intention of the Comuri was to focus on data only, but it did not go well. In particular, it is tricky to distinguish between data resources and no-data resources. As your rightly pointed-out, one has to forget about a "single URI scheme". But even trying to specify a "consistent URI schemes" is a swamp as discussions soon go into classifications such "collection", "subject", "department", etc. Hence the reason for going into a syntactic view of URI: "Common sense URIs: human and machine friendly, compact, simple, and with mnemonics" In other words: guidelines on easy conventions implementable with existing systems. Indeed, many usages do not need variants or other complex aspects in Comuri (e.g., empty query) that requires new development in the server. Regards Tomas > 3. Comuri > Your comments are welcome. Specification is about making concrete decisions. Stating the obvious, we are not producing laws that people must follow: they will follow specifications they find useful. > > By the way, some specifications become laws when parliaments say so :-) Again, in my personal opinion, this working group would be better delivering a "URI Scheme Best Practices" document that recommends some general best practices for defining consistent URI schemes and which discusses the available options for achieving them, rather than a specification that attempts to define a single URI scheme. A best practices document would provide useful support for people wanting to publish data to the web and benefit from the experience of others. There are existing documents in this space which could be used as input, so there is experience to draw on. There are features in the Comuri specification which, if useful, might be worth defining as a separate specification. For example it *might* be useful to standardise a extension of HTTP content negotiation that specifies a way to use URL parameters and/or path components to perform negotiation in conjunction with existing HTTP options. That is one feature of the scheme you define. That specification could then be implemented by people building web frameworks, etc. But that seems like something that is out of scope for this group.
Received on Monday, 8 September 2014 12:18:51 UTC