The assumption of all of this is that HTML documents are viewed in a
browser, not in SDS, and that documents or records created in SDS are
converted to HTML again each time they are changed, as you are doing with
the 144748.htm.
.. There should never be a problem of trying to fix SDS code.
If you consider that it is necessary to allow the user to create HTML codes
while originating SDS documents, then there is an issue. The "standard"
approach is to allow some sort of "escape" character. If we use '\' as an
escape character then we need to recognize as entities: \\ (backslash), \<, \>,
\&. This is still awkward, but more readable.
.. If we want to allow limited HTML then we need to parse the file to recognize
the difference between allowed HTML and characters that need to be entities.
This has been done, but I wouldn't tackle it in anything short of a real
programming language.
.. There is a concept called eText, which is used in some form on all Wiki
sites. It is essentially a way of allowing simplified markup to create HTML
documents. There are as many sets of rules as there are Wiki sites, but you
have seen some of it in my emails:
= Heading 1
== Heading 2
=== Heading 3
* Bulleted list
1. Numbered list
a. Lettered list
..
Text can be made *bold* with asterisks (sometimes **bold**), _italicized_,
etc.
.. The specific markup used varies, as I said. Sometimes it get complex enough
that I wonder about the value.
This is where the entire question of "foreign" documents comes up. Do we
expect SDS to handle documents in other formats well, or do we import /
export other documents from SDS?
.. You have taken the approach that *everything* ends up in SDS regardless of
origin, and that is certainly one approach. The clear advantage is that if
everything is in the same form, links and references are uniform and can be
done anywhere that they are needed.
The more that presentation becomes an issue, the more sophisticated the
editor has to become, and the more complex certain aspects become. If we
wanted to support fonts in SDS, for example, we would need an entirely
different technology. If we want to create the occasional HTML page (letter,
document, etc.) then we can add a few markup features for use in SDS and
generate the HTML as needed. This is what you do now. We could enhance the
HTML with some (more) eText concepts, but doing much more than that
complicates matters greatly.
.. The Composer in Netscape 7, for example, is a fairly complete WYIWYG HTML
editor that generates clean HTML. There are several other editors that do
similar things. There is even an add-on for Word to produce reasonably clean
HTML. So, we could create nice HTML in several ways, if that were the goal.
Then, of course, we have the problem of integrating it into SDS in such a
way that it can all "play together".
At this point, I wouldn't try to do more than add minimal markup to SDS to
improve generated HTML, and then only if really necessary.
.. Once you have handled bulleted and numbered lists cleanly based on their
indentation, convert obvious URLs to links, and handle SDS references (all
of which you already do), and *possibly* a couple of things like bold and
underline, I don't see that anything more is necessary. If there are other
features you would like, we can discuss why and see what can be done.