Re: 2.3 URI Ambiguity

Hi Mark,

: > Is there a counterexample of the "avoid URI ambiguity"
: > practice that would help make that clear?
: > 
: > Is there enough critical mass in the concept of "indirect
: > identification" to warrant a definition of same?
: 
: The previous text went further into that, but I think it's good that
: this text did not.  IMO, indirect identification is ambiguous.
: Moreover, I don't know any other way to be ambiguous than to use
: indirect identification.  Maybe that's just me though; I'm happy to be
: shown to be incorrect, but 2.3 doesn't do that, AFAICT.

I think I can see a distinction between

    "What do you think about 'Moby Dick'?"

and

    "The person 'waldenm@optonline.net'"

in terms of ambiguity.  I'm not sure of the relevance to
Web Architecture, though.

I do think "indirect identification" can be unambiguous,
given certain constraints.  E.g., the above reference to me
through (what I assert to be) my e-mailbox is unambiguous,
unless my wife and I are sharing the mailbox.
: 
: I also wanted to point out that my previous concern[1], which Dan
: suggested[2] that the revised text may address, still applies to this
: text.  Specifically, it seems to take a position on httpRange-14 (the
: wrong one in fact, otherwise I wouldn't have mentioned it 8-).

That can be easily worked around in the example by
simply asserting (as I did above) that the URI identifies a
mailbox, and then going from there.  That in no way says
that a similar-looking URI does not identify Mark Baker.

: 
: As for how to move forward, I'd personally just like to see the existing
: good practice note combined with a single example describing what
: ambiguity is; the database merging one seems fine (minus the preamble).

Agreed.  And one other little change: please word
best practices in the positive, i.e., the title of the best practice
should be a pattern, not an anti-pattern:

"Best Practice: Use URIs Unambiguously"

not

"Best Practice: URI Ambiguity"

Walden

Received on Monday, 1 December 2003 10:24:53 UTC