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