[Design] Human readable URL's in Vista / Chandler

[Andy Hertzfeld]

Hi Michael,

           One reason for referring to an object through a view, rather 
than more directly as you suggest, is that it allows the view to filter 
which fields of the object are revealed.  For example,   
"Contacts/Coworkers/Mitch Kapor" might only reflect work-related fields, 
while "Contacts/Friends/Mitch Kapor" might omit work-related fields. 
 Note that doesn't preclude us from also referring to objects more 
directly or by lower level names like object ids when appropriate.

          The plan for the human-readable names was to let each class 
register one or more names for their objects based on whatever fields 
made the most sense; when a name is not unique, it could disambiguate 
using an incrementing integer like you suggest or perhaps a date or time 
(I didn't deal with name conflicts in Vista, so I didn't have to work 
that out in detail).  I agree that once a name is assigned, it shouldn't 
change if other objects are deleted.

-- Andy

Michael R. Bernstein wrote:

>Andy,
>
>Thank you for producing this overview document describing the Vista
>prototype. I'll be responding in a series of postings to the mailing
>list, each focusing on some narrow aspect I'd like to comment on, or ask
>for more clarification.
>
>For those who are just tuning in to the mailing list, I am commenting on
>this document: http://www.osafoundation.org/Vista_prototype.htm
>
>Human readable URL's in Vista / Chandler
>========================================
>
>>From the section 'URL-based, Web style Navigation':
>
>    "We attempt to make the URLs as simple and user-oriented as much as
>    we can, containing user-level names of packages, views and objects
>    instead of machine-level identifiers or addresses like GUIDs. For
>    example, the URL for Mitch's contact information stored in John's
>    repository might be
>    "vista://john@osafoundation.org/Contacts/Coworkers/Mitch Kapor". The
>    identifier used for an object is defined by the class of the object,
>    so different types of objects can describe themselves in the way
>    best suited to the type of objects, using internal object IDs only
>    as a fallback."
>
>I approve of the intent to use human legible path elements as much as
>possible, but I have some comments on how Vista implements this idea. In
>the following discussion, I am going to omit the
>'vista://john@osafoundation.org/' portion of all URLs for brevity's
>sake.
>
>In the example given ('/Contacts/Coworkers/Mitch Kapor'), Mitch's
>contact information could presumably appear in other views as well, such
>as '/Contacts/Friends/Mitch Kapor' or '/Contacts/US/CA/San
>Francisco/Mitch Kapor'). This gives us several paths to access the same
>object (seemingly a positive thing), but it also would mean that the
>path to an object could change depending on it's attributes, suddenly
>invalidating a reference to an object.
>
>I think that the URL to an object should only include those path
>elements that are necessary to identify the object, in this case that
>would be '/Contacts/Mitch Kapor'.
>
>Now, that isn't to say that you shouldn't be able to *navigate* to
>'/Contacts/Coworkers' and see the list of coworker's contacts on John's
>system (including Mitch contact), just that the 'link' to an individual
>item wouldn't include the steps that you took to reach it.
>
>Now, if the URL of an item does not include the navigation steps taken
>by the user to reach it, it makes sense to display that information in
>an easily usable form as a breadcrumb navigation bar:
>
>john@osafoundation.org > Contacts > Coworkers > Mitch Kapor
>
>... probably in the top margin of the view. I'll post more about this
>idea in another email.
>
>Another problem with human readable identifiers for individual items, is
>that of disambiguation. What do we do about items that would have the
>same human readable identifier? For example, let's say I have two 'John
>Smith' entries in my Contacts package. How does Chandler distinguish
>between them (not internally, but to someone navigating by URL)?
>
>Chandler could append a number to the identifier, so that one URL was
>'/Contacts/John Smith', and the second was '/Contacts/John Smith2'. I'd
>recommend the id being permanent, so that even if the first contact is
>removed, the second contact is not renamed (unless he changes his name
>to 'Bob Jones').
>
>Finally, although Packages and Views can be readily identified with a
>human readable path-element name, there is a large category of Items
>that does not seem to be so amenable: Emails.
>
>A semi-readable URL for an email might take the form of
>'/Email/john@smith.com/12345' based on the sending email address, but
>I'm not sure that this is easy enough to remember to make it truly
>'human friendly', but at least it's not too ugly. In fact, I don't think
>that an entirely human friendly URL that uniquely identifies an email
>item is possible, and there are other item types that have the same
>problem. 
>
>Cheers,
>
>Michael Bernstein.
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Design" mailing list
>http://lists.osafoundation.org/mailman/listinfo/design
>  
>