How about lines AK1706, AK1728, AK1730 ..., AK1802, AK1999, AK2023, AK2077
..
I can accept arguments that say that links are not needed on these
paragraphs, including on your commentary (none of which has links), but
missing links on *some* paragraphs means that there are *not* links on
*every* paragraph. Whether they are necessary is a different issue.
..
I have no quarrel with the double dots. They work fine, particularly when
aligned with the text as they are. My interest in putting anchors at the end
of paragraphs was to do so in the SDS records themselves, as they are less
obtrusive (to me) than the current anchor mechanism, but *I repeat* this is
a conjecture about future directions, not about current implementation.
My major interest in maintaining anchors on every paragraph, at the end of
the paragraph, and based on a non-reused node id, is simply that this is a
technique that can be employed in the future that is simple and universal
and simply skips all questions of where there should be anchors.
.. Anchors as implemented are fine for this implementation. No change is
necessary. See my notes on viewpoints relating to SDS, especially
Anchors are valuable, both in the SDS records and in the resulting
HTML
..
Double dots work fine since they are on a line by themselves and we have
no requirement that they be human readable for use in other written
documents that do not understand hyperlinks
..
I then ask, how many ways do I know to do that, starting from exactly where I
am? Answer; SDS code which I cannot modify, the various systems of Perl code
that do something similar, one of which deals with plain text and places
anchors at the end of paragraphs.
..
Then I ask what would be involved in piecing together a system that begins to
look a little bit like SDS from code that I have.
..
I have Perl code that handles the node ID mechanism, a text markup system,
etc. which provides one possible avenue for developing a prototype SDS
system relatively quickly, using tools that I have and understand. This
discussion is to determine if such a mechanism would work well enough to be
applied to some future development of SDS or an SDS-like product.
..
This is *not* an argument that there is any difficulty at all with the
current mechanism in the current version of SDS.
..
== Where I am Going with This ==
When I consider that the Blosxom weblog system uses a date / time directory
structure as SDS does, which is really its only interest except that it is
also Perl code, and can present date index navigation.
http://www.raelity.org/apps/blosxom/view.shtml ..
I have Perl code for handling a Wiki that uses the node ID mechanism for
generating anchors and creates clean XHTML,
..
By adding a really simple editor or even using the programming editor that I
like best, I am close to being able to produce an SDS prototype that has
neither language nor memory limitations.
..
Such a prototype would not be much more than a toy compared to the current
state of SDS, but it would put me further along than the C version of Medit
does. In essence, it would provide a parallel effort in a code base that I
understand for experimenting with some ideas that are so far away from SDS
that there is no real way to experiment with them there.
..
I will be going to work on another Boeing project soon. I hope to take SDS
there once I work out the environment and get transfer mechanisms to keep
the systems synched.
..
Whether I can take SDS or not, I *will* develop some sort of chronologically
indexed, text based record to accompany all of the documents, their
locations, versions, descriptions, etc., and a mechanism to launch them from
wherever they are referenced.
..
I would like to see the "Other Files" mechanism in SDS modified to use
"start" to launch associated programs such as Word or Excel, but that I
can't control. I would like to be able to launch a program or the browser
from an explicit link embedded in an SDS record as I can from several other
programs.
..
I may develop 3 or 4 different approaches for my own amusement. I expect
that pieces of these exercises will feed back into SDS in the form of
programs to handle parts of SDS externally.
..
My long term goal is to determine what features are essential to SDS, which
are the way they are because they "just grew" and which are the way they are
because that is the best that we know how to do or because there is some
basis in either science or philosophy for doing things that way.
..
This is one reason that I am looking at line numbers. As implemented, they
make it extremely difficult to replace the Medit basic editor with drop-in
code from elsewhere. I am therefore looking at ways to support SDS line
numbers in other editors, support a different sort of line numbers (just
count from 1), etc. to see how best to develop something that meets all of
the SDS requirements while breaking as little as possible.
..
Line Numbering in SDS
I have a programmer's text editor that I have used for years. It has a
full-blown programming language for constructing macros. As an editor, it is
nothing like SDS. I can, however, devise a format that does everything an
SDS record does that doesn't rely on the way that SDS does it and develop
much of an SDS type application using that editor. It isn't a good long-term
approach because the editor is enough different to make *you* hate it. It
could, however, form the basis of a proof-of-concept that would allow me to
work with code for another editor that would give a "look and feel" that is
much closer to SDS.
..
For example, MultiEdit changes its characteristics based on file extensions
to support different programming languages (.c, .h for C programming; .pas,
.frm for Delphi; etc.). The fact that SDS files have no extension makes it
difficult to get special treatment for them. If I give them a .sds extension
or something similar, then I can write code to treat those files specially
as SDS records. I *may* be able to work some way to fake out the mechanism
to recognize SDS records from the path, the heading, or some other way, but
changing the extension is the easy way.
..
SDS depends on wrapping some lines and not others as such things as
reference and control lines are not intended to be edited directly. I don't
think that there is an easy way to do this in MultiEdit, but there may be if
I dig into it (turn of word wrap and turn on overtype when a line is
recognized?).
..
== A New SDS ==
All of this is in pursuit of a new and improved SDS. The fact that I want
SDS to be new and improved doesn't mean that the current one is terrible,
just that it can be improved.
..
Given that, I am attempting to employ my several decades of software
development experience toward defining what that new program could / should
look like, while at the same time learning enough about what SDS does, why
it does it, why it does it the way it does it, and which parts have to
remain much as they are and which can be done differently, and what can be
added that SDS doesn't do yet.
.. Thanks,