[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Re: terminology for purple numbers]



Herewith the redirected message. I wonder if it will be
part of the original thread, or start a new one?    (01)

-------- Original Message --------
Subject: Re: terminology for purple numbers
Date: Wed, 25 Jul 2001 15:23:53 -0700
From: Eric Armstrong <eric.armstrong@eng.sun.com>
To: Eugene Eric Kim <eekim@eekim.com>
References:
<Pine.LNX.4.33.0107231520340.1186-100000@hugh.burdenslanding.org>    (02)

I'd go with "aug". Keep it three characters, but its more
recognizable than "aln".    (03)

At least, it's recognizable to those who are conversant with
Augment. It think "toc" is recognizable to everyone. But I
guess its worth keeping "back-references" that point to the
origins of the addressing convention.    (04)

(I admit that the simplicity and elegance of 1A1A... notation
had eluded me completely until I saw it in Augment.)    (05)

For that matter, you could also "nls", since that is where
the notation *really* came from.    (06)


Eugene Eric Kim wrote:
> 
> On Mon, 23 Jul 2001, Eric Armstrong wrote:
> 
> > 1. Can you give me a little more background on the change in meaning
> >    you refer to?
> 
> In Augment, "sid" refers to "statement IDs".  "statements" are nodes in
> Augment files, generally consisting of a single paragraph or header.
> Augment SIDs are unique, immutable, numerical addresses, and are preceded
> by a zero.  An example of an Augment SID is 045.
> 
> Murray is proposing that sid refer to "structural IDs", or the Augment
> structural location numbers.  An example is 2C3, which refers to the third
> subparagraph of the third subparagraph of the second paragraph.
> 
> So we would essentially have the following mapping:
> 
>     Augment                        Purple/plink    Example
>     statement IDs (sid)         => nid             045
>     structural location numbers => sid             2C3
> 
> > 3. In general, I'm in favor of NOT using "ID" for anything but
> >    the ID, where ID will eventually be a globally unique
> >    node identifier (nid). (gun?)
> 
> Good point.
> 
> >    So, for a structure identifier, I'd be inclined to use
> >    "path" or "relpath" in the name.
> 
> "path" is okay, but to many people will imply XPath.
> 
> >   * Table of Contents path: TOC
> >     +-I kind of like this, because the notion of a TOC
> >       represents hierarchical structure. It assumes the
> >       the kind of hierarchical path identification we are
> >       trying to capture. So "toc:1A3B" pretty much tells
> >       me at glance how to interpret "1A3B".
> >     +-Having the name be radically different from NID
> >       also helps to identify the thing at a glance,
> >       and prevents confusions, typographic errors, and the
> >       like.
> 
> Not bad.  Another alternative would be to just use "aloc" or "aln" for
> "Augment location number."  In fact, this is growing on me, because it
> identifies it as an Augment-style addressing scheme, thus retaining its
> heritage while not confusing it with modern addressing schemes.
> 
> -Eugene
> 
> --
> +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+
> |       "Writer's block is a fancy term made up by whiners so they        |
> +=====  can have an excuse to drink alcohol."  --Steve Martin  ===========+    (07)