Re: 2.3 URI Ambiguity

: > What about something like this:
: > 
: >   "In Web architecture, URIs identify resources. Outside of Web 
: >    architecture, the URI string can be useful in any number of
: >    roles (e.g., as database keys), including as identifiers. For 
: >    instance, "mailto:nadia@example.com" can be used by the organizers 
: >    of a conference as an identifier for Nadia; parties involved in 
: >    the context understand and agree to that local policy. Certain
: >    properties of URI strings in the Web architecture, such as their
: >    potential for uniqueness, make them appealing for non-Web contexts. 
: >    In the Web architecture, "mailto:nadia@example.com" only
: >    identifies an Internet mailbox. The URI is not ambiguous within
: >    the Web architecture merely because the URI string serves different
: >    roles in other contexts. URI ambiguity arises when an agent uses
: >    the same URI to identify two different *Web* resources.

Ian,

It's now clearer that you can use URI outside the scope of the
Web, and that Web best practices don't apply there,
necessarily.

I'm still seeing a few problems, though.

1. Will the reader have enough information to know what
is meant by "outside of Web architecture"?  I'm not sure I do,
and likewise I'm not sure I see that the database application
in question is "outside of Web architecture", unless I'm given
more information.  It may be clearer to make the distinction
as "URI used for identification tasks other than fetching
representations via web protocol".  Is that the distinction?

2. I'd say "database keys" is still identification, and that
there aren't any uses for URI except for identification, in
one form or another.  So, I think you could remove the
assertion that URI are "used in any number of roles..." without
harm.

3. The above text now takes a very strong position on the
resolution of httpRange-14, but it need not.  "In the Web
architecture, mailto:nadia@example.com may identify a mailbox,
not a person."

4. The space given to explaining the exception seems
disproportionate: only the last sentence hits the meat of the
matter.  And there, I think examples of poor practice are
badly needed.  Were there some and I missed them?  I think
if those examples were included, I'd be satisfied and would
not need to look at examples from outside the architecture.

Thanks,
Walden

Received on Tuesday, 2 December 2003 12:51:43 UTC