Notes from my review of URNs, Namespaces and Registries

Henry/Dave,  

These are my notes from the review;

Overall-

  I thought this was a great paper and did a good job.  I'd love to see
what folks from the XRI working group think of it.

Some specific notes;

1) Section 1;  Avoiding URI aliases.. "A URI owner SHOULD NOT associate
arbitrarily different URIs with the same resource." -  This is actually
done all the time, if you look at most advertisements that reference a
URL you'll quite often see http://myway.highway.com/go/fo which is a
'shortcut' URL to the final destination.  The idea is that everything
stays the same except for 'fo' to repeat customers just have to remember
the 'keyword' in order to get to the page instead of the fully qualified
URL.  This is one of those cases where 'real-world' Marketing may
collide with pure web architecture, but I thought I'd point it out.

2) URI opacity; "Agents making use of URIs SHOULD NOT attempt to infer
properties of the referenced resource.".  I believe in the use of
metadata in the URI we state that this may be ok for 'people' but not
for systems.  If so these two draft findings are in conflict and should
be resolved (or clarified) before publication.

3) You explain quite well why the proposals do not raise to the level of
a new URI scheme, but you never explain when it would be justified.. I
feel your implying it, maybe even stating it indirectly.. But its worth
calling out specifically.  I think that would be a extremely valuable
addition to the web arch.

4) Section 4.2 your conclusion points out that myRI would not be
auto-completed, but isn't this only because its not adopted as a
standard?  If it was and used, the programs/spell check over-time would
treat it similar to an http:// prompt.  I'd suggest removing the last
sentence.

5) I'm not sure that imagining a scenario where OASIS no longer exists
is good form.  We work well together as complementary bodies.  Maybe
another example would be better suited.

6) 4.5 - summary - need to just come out and say because they are so
similar and because everything you can do with an XRI you can do with
http then adopting an xri scheme would actually do more harm
(confusion/fragmentation) than it would solve.

7) DaveO has asked a few notes which appear to still be in the finding
:) they need to be resolved.  In 5.2.1 the note about XRI changing the
doc path... XRI doesn't address this since the paths are logical and
therefore should not have to change.  Your example where an editor may
be in the doc path would still be an issue if the XRI was defined that
way.

8) in 5.2.2 last paragraph you talk about how to do redirects.  In cases
where large redirects are done, there is normally a 404 service (program
that's executed on the 404) which uses lookup tables for redirection.
This allows for generated mappings as well as logging of the
transaction.   You may want to add this to the explanation as well.

Sorry, sounds like a lot of feedback, I really did like the paper.

-Ed

Received on Monday, 12 June 2006 01:28:02 UTC