Re: CoIN: Composition of Identifier Names

Thanks all for your informative and enlightening responses :)

Until Ivan's response that clients "are allowed to treat the URI as
structured if [...] the server tells the client how its URI is
structured", I would still have believed that the treat as opaque
principle would hold.  CoIN or URI templates (or some other
unspecified system) would fulfill this condition, if published by the
server that maintains the URI, and a non-standard is permissible.

However until then, the structure isn't specified by a standard (in
any meaningful usage of the term) such as is the case for an HTML
form, so the client should still treat the URI as opaque.  No that
doesn't preclude the server from publishing how it constructs its
URIs, but it makes it somewhat pointless from a software perspective
when the client software should still not infer information from that
about the resource the URI identifies.  Including, one imagines, the
existence of the resource the constructed URI identifies.

If all that was desirable was human understanding, a regular web page
would be better than a machine interpretable document.

Many thanks,

Rob

On Tue, Apr 13, 2010 at 11:52 AM, Ivan Žužak <izuzak@gmail.com> wrote:
> Hi all,
>
> Here's the juice on URI opacity, right from Roy [1].
>
> The important bits:
>
> ""Opacity of URI" only applies to clients and, even then, only to
> those parts of the URI that are not defined by relevant standards.
> Origin servers, for example, have the choice of interpreting a
> URI as being opaque or as a structure that defines how the server
> maps the URI to a representation of the resource. Cool URIs will
> often make a transition from being originally interpreted as
> structure by the server and then later treated as an opaque
> string (perhaps because the server implementation has changed
> and the owner wants the old URI to persist). The server can make
> that transition because clients are required to act like they
> are ignorant of the server-private structure.
>
> Clients are allowed to treat a URI as being structured
> if that structure is defined by standard (e.g., scheme and
> authority in "http") or if the server tells the client how its
> URI is structured. For example, both GET-based FORM actions and
> server-side image map processing compose the URI from a
> server-provided base and a user-supplied suffix constructed
> according to an algorithm defined by a standard media type."
>
> Ivan
>
> [1] http://tech.groups.yahoo.com/group/rest-discuss/message/5369
>
>
> On Tue, Apr 13, 2010 at 19:30, Richard Cyganiak <richard@cyganiak.de> wrote:
>> On 13 Apr 2010, at 18:04, Pierre-Antoine Champin wrote:
>>>
>>> 2/ Given a URI, a software should not try to reverse-engineer it.
>>> However, the axiom does not prevent that a software be given a *rule* to
>>> *produce* new URIs.
>>>
>>> As a matter of fact, I would be surprised that TBL would discourage this
>>> very mechanism which underlies all HTML-based forms (at least those
>>> using the GET method). A form is nothing else than the specification of
>>> a *whole set* of URIs, plus the technical tool to produce them easily in
>>> your browser.
>>
>> Didn't read this before writing my own response -- well said!
>>
>> Cheers,
>> Richard
>>
>>
>>>
>>>
>>>  pa
>>>
>>> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
>>> [2] http://www.w3.org/DesignIssues/Axioms.html#opaque
>>>
>>> On 13/04/2010 17:11, Robert Sanderson wrote:
>>>>
>>>> A quick question...
>>>>
>>>> 2010/4/13 Niklas Lindström <lindstream@gmail.com>:
>>>>
>>>>> I've found it very valuable to formally declare the pieces from which
>>>>> an URI is to be composed of. Especially in our environment where we
>>>>> have a central design of the URI:s, but decentralized publishing of
>>>>> data (which is of a somewhat rich and varied nature).
>>>>
>>>>
>>>> How does this mesh with URIs being opaque?  If the URIs were actually
>>>> opaque and treated as such, then formally declaring the parts would be
>>>> a non-issue.  It seems that this ideal is being increasingly watered
>>>> down or ignored... is that intentional, and is it a good or bad thing?
>>>>
>>>> Thoughts?
>>>>
>>>> Rob Sanderson
>>>>
>>>
>>>
>>
>>
>>
>

Received on Tuesday, 13 April 2010 19:26:18 UTC