CONTACTS 
0201 - Dynamic Alternatives                                                                                                                                               O-00000793 0101
020101 - Mr. Garold L. Johnson

SUBJECTS
Gary Proposes Adding Anchors to End of Paragraphs Using External Tech
Addressability Gary Wants Links at End of Para to Beginning of Para f
Frustrated Gary Wants to Develop Code Proposed Purple Numbers because
Gary Offers to Work on Creating Next Version of SDS Starting by Revie
Purple Numbers Gary Wants Links at End of Para to Beginning of Para f
Addressability Links to History Context Authority Reveal Correlations
Addressibility Links in Email Improved by SDS Anchors, 000810
Explict Links Make Connections to SDS Record Fast and Easy
Addressability Anchors on Every Para Enables Links Intelligence Summa
Purple Numbers Links at End of Para to Beginning of Para for Addressa
Links Addressability Anchors on Every Para Email Improved, Doug Engel
Addressability Explicit Links Gary Wants them on Every Para and Creat

2314 -
2314 -    ..
2315 - Summary/Objective
2316 -
231601 - Follow up ref SDS 80 0000, ref SDS 73 0000.
231602 -
231603 - Gary's letter yesterday has a link to a record on 030119, ref SDS 73
231604 - 347O, that explains ideas for adding explicit links at the end of a
231605 - paragraph to the beginning of the paragraph, which are described as
231606 - Purple Numbers, and says in part....
231607 -
231608 -         [On 030121 improved addressability by adding anchors to every
231609 -         para with the save function. ref SDS 81 KO4U
231611 -       ..
231612 -      If we use the Purple Wiki node id technique of putting unique
231613 -      node ids at the *end* of *every* paragraph, we could easily place
231614 -      anchors on *every* paragraph unobtrusively. ref SDS 72 KI6K
231616 -       ..
231617 -      A translation program could translate the SDS database. It would
231618 -      require republishing the HTML, but we now have tools to do that.
231619 -
231620 - ...and which seems to implement a method Doug Engelbart used in the
231621 - OHS/DKR launch plan submitted on 001025. ref SDS 14 00VU
231623 -  ..
231624 - Background on addressability in SDS records and external documents is
231625 - reported on 021230. ref SDS 54 M16L
231627 -  ..
231628 - Addressability adding explicit links was upgraded on 021230,
231629 - ref SDS 54 0001, and again a few days later on 030101. ref SDS 56 0001
231631 -  ..
231632 - On 020320 features were developed to provide explicit links,
231633 - ref SDS 27 0001, that are unobtrusive. ref SDS 27 NJ5M  A few days
231634 - later, on 020325 Gary commented favorably on this new feature saying
231635 - in part...
231636 -
231637 -       The double dots work quite well. They are unobtrusive and still
231638 -       allow simple copying of the link. Very nice. ref SDS 28 CQ5O
231640 -  ..
231641 - Since the work on 020320, on 021230 and on 030101 enable people to
231642 - easily place anchors on every paragraph unobtrusively, as Gary noted
231643 - in his letter on 020325, the goals to do the same thing with Purple
231644 - Numbers seem to be conflicting, in that the objecitve is already
231645 - accomplished.
231646 -
231647 -         [On 030121 improved addressability by adding anchors to every
231648 -         para with the save function. ref SDS 81 KO4U
231649 -
231651 -  ..
2317 -
2318 -
2319 - 1740
2320 -
232001 - Submitted ref DIT 1 0001 to Gary asking about objectives for Purple
232002 - Numbers in light of his letter on 020325, per above. ref SDS 0 O54H
232004 -  ..
232005 - The letter to Gary explains that we (I especially) have to work hard
232006 - at not becoming overly dogmatic on matters of personal taste.
232007 - Jefferson, for example is quoted as observing that on matters of
232008 - fashion go with the prevailing wind, and on matters of principle stand
232009 - firm. Unfortunately, Tom was less helpful on distinguishing fashion
232010 - from principle.  In any case, here is my try. ref DIT 1 SF9I
232012 -  ..
232013 - Pointed out that we we seem to be accomplishing his objective, and
232014 - cited the record on 00125 as an example of explicit links using double
232015 - dots which seems to preempt the need for Gary's proposal to use Purple
232016 - Numbers. ref DIT 1 YF5M
232018 -  ..
232019 - Gary sent a letter ref DRT 1 0001 discussing the linking issue, and
232020 - explaining ideas on SDS development. ref SDS 0 OO9W
232022 -  ..
232023 - He says in part concerning explicit links....
232024 -
232025 -      We have different definitions of *every*. In the record to which
232026 -      you refer [on 001025, ref SDS 14 00VU,....
232027 -
232028 -         http://www.welchco.com/sd/08/00101/02/00/10/25/095632.HTM#00VU
232030 -       ..
232031 -      You say: Notice for example lines AK1701, AK1713, and AK1719.
232033 -       ..
232034 -      And I say: How about lines AK1706, AK1728, AK1730 ..., AK1802,
232035 -      AK1999, AK2023, AK2077. ref DRT 1 N46I
232036 -
232037 -         [On 030121 improved addressability by adding anchors to every
232038 -         para with the save function. ref SDS 81 KO4U
232040 -       ..
232041 -      I can accept arguments that say that links are not needed on
232042 -      these paragraphs, including on your commentary (none of which has
232043 -      links), but missing links on *some* paragraphs means that there
232044 -      are *not* links on *every* paragraph. Whether they are necessary
232045 -      is a different issue. ref DRT 1 Y46N
232047 -       ..
232048 -      My major interest in maintaining anchors on every paragraph, at
232049 -      the end of the paragraph, and based on a non-reused node id, is
232050 -      simply that this is a technique that can be employed in the
232051 -      future that is simple and universal and simply skips all
232052 -      questions of where there should be anchors. ref DRT 1 957J
232054 -       ..
232055 -      Anchors as implemented are fine for this implementation. No
232056 -      change is necessary. ref DRT 1 U79G  See my notes on viewpoints
232057 -      relating to SDS, especially [on 030119. ref SDS 77 0034]
232058 -
232059 -         http://www.welchco.com/sd/08/GLJDY/02/03/01/19/121559.HTM#0034
232061 -       ..
232062 -      I am looking at the fact that we have discovered that:
232064 -             ..
232065 -         •  Anchors are valuable, both in the SDS records and in the
232066 -            resulting HTML, ref DRT 1 U79G
232068 -             ..
232069 -         •  Double dots work fine since they are on a line by
232070 -            themselves and w have no requirement that they be human
232071 -            readable for use in other written documents that do not
232072 -            understand hyperlinks, ref DRT 1 789W
232074 -       ..
232075 -      I then ask, how many ways do I know to do that, starting from
232076 -      exactly where I am? Answer; SDS code which I cannot modify, the
232077 -      various systems of Perl code that do something similar, one of
232078 -      which deals with plain text and places anchors at the end of
232079 -      paragraphs. ref DRT 1 7842
232080 -
232081 -         [On 030121 improved addressability by adding anchors to every
232082 -         para with the save function. ref SDS 81 KO4U
232084 -       ..
232085 -      Then I ask what would be involved in piecing together a system
232086 -      that begins to look a little bit like SDS from code that I have.
232087 -      ref DRT 1 7848
232089 -       ..
232090 -      I have Perl code that handles the node ID mechanism, a text
232091 -      markup system, etc. which provides one possible avenue for
232092 -      developing a prototype SDS system relatively quickly, using tools
232093 -      that I have and understand. This discussion is to determine if
232094 -      such a mechanism would work well enough to be applied to some
232095 -      future development of SDS or an SDS-like product. ref DRT 1 Z95H
232097 -       ..
232098 -      This is *not* an argument that there is any difficulty at all
232099 -      with the current mechanism in the current version of SDS.
232100 -      ref DRT 1 T95O
232102 -       ..
232103 -      == Where I am Going with This ==
232105 -       ..
232106 -      When I consider that the Blosxom weblog system uses a date / time
232107 -      directory structure as SDS does, which is really its only
232108 -      interest except that it is also Perl code, and can present date
232109 -      index navigation. ref DRT 1 746I
232110 -
232111 -         http://www.raelity.org/apps/blosxom/view.shtml
232113 -       ..
232114 -      I have Perl code for handling a Wiki that uses the node ID
232115 -      mechanism for generating anchors and creates clean XHTML,
232116 -      ref DRT 1 D53H,
232118 -       ..
232119 -      By adding a really simple editor or even using the programming
232120 -      editor that I like best, I am close to being able to produce an
232121 -      SDS prototype that has neither language nor memory limitations.
232122 -      ref DRT 1 Z53L
232124 -       ..
232125 -      Such a prototype would not be much more than a toy compared to
232126 -      the current state of SDS, but it would put me further along than
232127 -      the C version of Medit does. In essence, it would provide a
232128 -      parallel effort in a code base that I understand for
232129 -      experimenting with some ideas that are so far away from SDS that
232130 -      there is no real way to experiment with them there. ref DRT 1
232131 -      064G
232133 -       ..
232134 -      I will be going to work on another Aerospace company project soon. I hope to
232135 -      take SDS there once I work out the environment and get transfer
232136 -      mechanisms to keep the systems synched. ref DRT 1 464N
232138 -       ..
232139 -      Whether I can take SDS or not, I *will* develop some sort of
232140 -      chronologically indexed, text based record to accompany all of
232141 -      the documents, their locations, versions, descriptions, etc., and
232142 -      a mechanism to launch them from wherever they are referenced.
232143 -      ref DRT 1 Q65I
232145 -       ..
232146 -      I would like to see the "Other Files" mechanism in SDS modified
232147 -      to use "start" to launch associated programs such as Word or
232148 -      Excel, but that I can't control. I would like to be able to
232149 -      launch a program or the browser from an explicit link embedded in
232150 -      an SDS record as I can from several other programs. ref DRT 1
232151 -      I65O
232153 -       ..
232154 -      I may develop 3 or 4 different approaches for my own amusement. I
232155 -      expect that pieces of these exercises will feed back into SDS in
232156 -      the form of programs to handle parts of SDS externally.
232157 -      ref DRT 1 1E6L
232159 -       ..
232160 -      My long term goal is to determine what features are essential to
232161 -      SDS, which are the way they are because they "just grew" and
232162 -      which are the way they are because that is the best that we know
232163 -      how to do or because there is some basis in either science or
232164 -      philosophy for doing things that way. ref DRT 1 6E7G
232166 -       ..
232167 -      This is one reason that I am looking at line numbers. As
232168 -      implemented, they make it extremely difficult to replace the
232169 -      Medit basic editor with drop-in code from elsewhere. I am
232170 -      therefore looking at ways to support SDS line numbers in other
232171 -      editors, support a different sort of line numbers (just count
232172 -      from 1), etc. to see how best to develop something that meets all
232173 -      of the SDS requirements while breaking as little as possible.
232174 -      ref DRT 1 IE7M
232176 -       ..
232177 -      Line Numbering in SDS [discussed in my record on 030119,
232178 -      ref SDS 72 0001]...
232179 -
232180 -         http://www.welchco.com/sd/08/GLJDY/02/03/01/19/055635.HTM
232182 -       ..
232183 -      I have a programmer's text editor that I have used for years. It
232184 -      has a full-blown programming language for constructing macros. As
232185 -      an editor, it is nothing like SDS. I can, however, devise a
232186 -      format that does everything an SDS record does that doesn't rely
232187 -      on the way that SDS does it and develop much of an SDS type
232188 -      application using that editor. It isn't a good long-term approach
232189 -      because the editor is enough different to make *you* hate it. It
232190 -      could, however, form the basis of a proof-of-concept that would
232191 -      allow me to work with code for another editor that would give a
232192 -      "look and feel" that is much closer to SDS. ref DRT 1 YE8K
232194 -       ..
232195 -      For example, MultiEdit changes its characteristics based on file
232196 -      extensions to support different programming languages (.c, .h for
232197 -      C programming; .pas, .frm for Delphi; etc.). The fact that SDS
232198 -      files have no extension makes it difficult to get special
232199 -      treatment for them. If I give them a .sds extension or something
232200 -      similar, then I can write code to treat those files specially as
232201 -      SDS records. I *may* be able to work some way to fake out the
232202 -      mechanism to recognize SDS records from the path, the heading, or
232203 -      some other way, but changing the extension is the easy way.
232204 -      ref DRT 1 QF4F
232206 -       ..
232207 -      SDS depends on wrapping some lines and not others as such things
232208 -      as reference and control lines are not intended to be edited
232209 -      directly. I don't think that there is an easy way to do this in
232210 -      MultiEdit, but there may be if I dig into it (turn of word wrap
232211 -      and turn on overtype when a line is recognized?). ref DRT 1 ZF5F
232213 -       ..
232214 -      == A New SDS ==
232216 -       ..
232217 -      All of this is in pursuit of a new and improved SDS. The fact
232218 -      that I want SDS to be new and improved doesn't mean that the
232219 -      current one is terrible, just that it can be improved.
232220 -      ref DRT 1 TF5M
232222 -       ..
232223 -      Given that, I am attempting to employ my several decades of
232224 -      software development experience toward defining what that new
232225 -      program could / should look like, while at the same time learning
232226 -      enough about what SDS does, why it does it, why it does it the
232227 -      way it does it, and which parts have to remain much as they are
232228 -      and which can be done differently, and what can be added that SDS
232229 -      doesn't do yet. ref DRT 1 5G6J
232230 -
232231 -
232232 -
232234 -  ..
2323 -
2324 -
2325 - 2018
2326 -
232601 - Later in the evening, I called Gary and asked him about his goals for
232602 - using Purple Numbers in SDS, per his letter yesterday. ref SDS 0 0001
232604 -  ..
232605 - Gary indicated during our call that he feels the current design of
232606 - adding double dots on every paragraph is effective.  He feels that
232607 - addressability should be more automated so it does not depend on using
232608 - Alt F9, developed on 030101, ref SDS 56 0001, because often his work
232609 - does not require further editing that uses Alt F9, so it is easy to
232610 - omit this step, and having to justify a paragraph solely to add
232611 - addressability seems like an extra step that can be accomplished more
232612 - thoroughly and consistently with automated code.
232614 -        ..
232615 -       [On 030121 developed automated code for addressability.
232616 -       ref SDS 81 YI5K
232618 -  ..
232619 - Gary makes a good point.  The record on 001025 had a lot of anchors
232620 - where they were needed for linking, but did not have anchors on every
232621 - paragraph.  Similarly, looking at Gary's SDS records, they have almost
232622 - no anchors on anything, reflecting the lack of links, and lack of
232623 - editing that requires justifing the text....
232624 -
232625 -       Editing in SDS....................... 030115, ref SDS 68 0001
232626 -       Assessment of SDS software........... 030116, ref SDS 70 0001
232627 -       SDS indexing and fixing.............. 030119, ref SDS 78 0001
232628 -       Multiple perspectives on SDS......... 030119, ref SDS 77 0001
232629 -       Bookmarking records..new SDS......... 030119, ref SDS 76 0001
232630 -       Searching for diary records.......... 030119, ref SDS 75 0001
232631 -       Entering records from notes.......... 030119, ref SDS 74 0001
232633 -  ..
232634 - This record shows that while assigning anchors to every paragraph is
232635 - fast and easy with the current design using Alt F9 to justify text,
232636 - there are grounds for automating this process further to make
232637 - addressability more comprehensive, and without requiring people to
232638 - remember to justify each paragraph.
232640 -  ..
232641 - During our call, Gary explained he considered using the Purple Numbers
232642 - design of adding anchors to the end of a paragraph, because that is
232643 - something he may know how to accomplish using code from other sources,
232644 - since he does not have access now to tools for modifying the code for
232645 - SDS.
232647 -  ..
232648 - Our objective for Gary's evaluation of SDS is to learn SDS based on
232649 - the current design, shown in the record on 020924, ref SDS 33 0001,
232650 - and to develop a work plan for improvement that can be implemented
232651 - under a joint agreement that is pending acceptance at the end of
232652 - February, per the letter to Gary on 021125, ref SDS 45 YG3K  On 021221
232653 - the date for submitting a development plan was extended to 030205.
232654 - ref SDS 51 F93J
232656 -  ..
232657 - Gary's letter today, per above, ref SDS 0 TR6W, appears to contribute
232658 - toward the development plan due on 030205.
232659 -
232660 -     [On 030208 Gary submitted work plan ideas. ref SDS 82 YT6O
232661 -
232662 -
232663 -
232664 -
232665 -
232666 -
232667 -
232668 -
232669 -
232670 -
232671 -
232672 -
232673 -
232674 -
232675 -
2327 -