[unrev-II] "purple numbers" -- use of, hierarchical

From: Eric Armstrong (eric.armstrong@sun.com)
Date: Mon Oct 29 2001 - 13:01:31 PST

  • Next message: Grant Bowman: "Re: [unrev-II] "purple numbers" -- use of, hierarchical"

    Peter Jones wrote:

    > I wonder whether purple numbering as it appears in a HTML document is
    > too concrete an address point if you move beyond simple HTML. Or
    > rather, to put it another way, when I point at a purple number anchor
    > with a link, what, in the world of DKRs, am I really pointing at? I
    > note that existing purple numbered documents don't seem to include
    > version information at the grain level in the p-number.

    Here, we have to be careful to distinguish between future DKR-style
    environments we might complement, and the potential for purpled HTML
    documents that we can use today. There is a lot we can do simply by
    adding purple numbers, due to the increased granularity potential for
    addressing. Versioning is a separate issue that has to be taken into
    account in the context of DKR designs.

    > So I guess I/we have two questions to ask:
    > 1) Are p-numbers like we presently see rich enough in information?

    In and of themselves, at this point in time, no. But they represent a
    dramatic step in the right direction.

    > 2) Are they in the right place in the system? E.g. should they be
    > hidden enablers instead of explicit UI content?

    Here, I think the answer is clear. Some form of the purple numbers must
    be explicitly visible. That's what makes it possible to grab them and
    use them. Pale purple in a small font was an inspired choice for the
    display -- they recede far enough into the background that they don't
    stand out, yet they are still visible.

    Hierarchical IDs, however, are another matter. I think we still have a
    bit of thinking to do on them. The big issue, in my mind is this:
       If I copy a link named A1A, and that section moves so it becomes A1D,

       I'll have a "camaflouged hole" in the form of a link that works, but
    which goes
       to different material than it did.

    For that reason, I think that even if a hierachical link displays the
    HID, underneath
    that it should probably use the node ID. So the link would look like
    this:
       <a href="023">A1A</a>

    That way, even if the material moves, the link will still be valid. More
    importantly, it will be pointing to the original materal. (Even though,
    at this point, it will mis-labeled.)

    About here, my thinking begins to branch off in a number of directions:
       1) Hierarchical IDs seem like fantastic shorthand in the user
    interface. I can
           type "b1c3" easily and quickly. -- But any link I create as a
    result of typing
           that should probably go to the nodeID, not the hierarchical ID.

       2) Perhaps the created link should actually say 023, instead of A1A.
    Then,
           "misnaming" is never an issue.

       3) Or perhaps the system, when it encounters a mislabeled link, could
    relabel
            it. So the link A1A would go to 023, which is now at A1D. The
    system
            might then relabel the A1A link so it reads A1D.

       4) For efficiency, systems probably need to maintain a translation
    table that
           maps nodeIDs --> hierarchical IDs. (Or maybe not. Not sure.)

    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
    Get your FREE VeriSign guide to security solutions for your web site: encrypting transactions, securing intranets, and more!
    http://us.click.yahoo.com/UnN2wB/m5_CAA/yigFAA/IHFolB/TM
    ---------------------------------------------------------------------~->

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II

    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



    This archive was generated by hypermail 2.0.0 : Mon Oct 29 2001 - 12:49:05 PST