🚀 go-pugleaf

[C. M. Sperberg-McQueen]
:
|   It's as though one insisted that a C compiler had to produce object code
|   from which the source code could be regenerated, and the regenerated
|   source code had to have all the comments, the white space, the macro
|   definitions, and the newlines of the original source, as well as having
|   trigrams in exactly the places where the original source had trigrams.
|   Otherwise we are going to tell all our friends and colleagues that the
|   C compiler is not fully conformant.
|
|   Since the C standard specifies that a parser cannot require a user to
|   use two spaces where one would suffice, or interpret two spaces
|   differently from one (outside of literal strings), some might argue
|   that a *conforming* C compiler *cannot possibly* preserve the information
|   that one, or two, or seven, spaces were used here, or here, or here.
|   Even if it's legal for a compiler to retain that information somehow,
|   it would surely be rather strange to say that *only* a compiler which
|   did that should count as fully conformant, which is what your
|   original proposal boils down to for SGML parsers.

This is a very good analogy, and as long as we're talking about a parser
doing its job, it's perfectly valid.

However, this discussion evolved from a desire to import and export SGML
documents into and out of some non-SGML environment, such as a database
system or an editor with its own internal format, and at if we hold onto
this context, and to the analogy with C, the "indent" program is probably
closer to a real comparison of functionality.

The "indent" program accepts a valid C program and produces another valid C
program adhering to a set of stylistic parameters, i.e., it reformats the
code so it looks "nicer".  There were a very long-winded and occasionally
informative thread on this in comp.lang.c some time ago, and the central
question was how to prove that the C program was the "same" before and
after running indent, and what "same" meant.  indent also restructures the
comments, and some people had major gripes about that, since their comments
were structured information in itself, used to extract documentation or to
describe the interface to the function in a semi-formal way.  A program
that could do a semantic diff on C code was also sought, for which spaces
and comments and abbreviated identifers and such syntactic noise were
deemed insignificant, and only "relevant" differences were reported.  I
didn't see this "search request" fulfilled.

I see a great need for software that accepts an SGML document and produces
another SGML document according to a set of parameters, such as support for
features, character sets, and concrete syntaxes.  Conversion between DTDs
would also be a natural function of such software.  (This would at least
fulfill Michael's desire for a "rename" functionality.)  Such a tool could
probably be built using a database or an editor with powerful export
functionality.

Best regards,
</Erik>
--
Erik Naggum                 ISO  8879 SGML                    +47 295 0313
Oslo, Norway                ISO 10744 HyTime          Watch this ^ space
<erik@naggum.no>            ISO  9899 C                 Memento, terrigena
<SGML@ifi.uio.no>           ISO 10646 UCS             Memento, vita brevis