🚀 go-pugleaf

In article <23275B@erik.naggum.no> Erik Naggum (SGML@ifi.uio.no) writes:
> Darrell Raymond <drraymon@watdragon.uwaterloo.ca> writes:
> |         SGML will result in non-portable, applications-program-dependent
> |         documents.
>
> equivalent to the claim found in some of the strongly-typed programming
> language advocacy groups:
> (1) C will result in non-portable, hardware-dependent programs.
 
I don't see the similarity. A more `equivalent' claim might be
 
(1) Any formal language-specification method will result in a
    proliferation of programming languages, all different, all requiring
    specialist compilers.
 
The syntaxes of PL/1 and Haskell are both specifiable by, say, BNF, but
but programs are certainly not portable between them. Now, it may be true
that given the VDM specification of PL/1 and the denotational-semantics
specification of Haskell, a program could `understand' both languages
well enough to translate between them. But this level of semantics (i.e.
the difference between VDM and BNF) is not present in SGML.
 
Even in the rigorous world of functional languages there are literally
hundreds of them, so I wonder you are so sure the same thing will not
happen to SGML.
 
> This claim has two possible interpretations:
> (1.1) There are inherent qualities in C such that it is impossible to
>  write portable and hardware-independent programs in it.
> (1.2) There are inherent qualities in C such that it is possible to
>  write non-portable and hardware-dependent programs in it.
> The difference between these interpretations is enormous: it's obvious
> that (1.1) is false, and equally obvious that (1.2) is true.  Those who
> claim (1) have invariably referred to the truth of (1.2) in defending
> their claim, and then turned around and applied the conclusion as if
> claim (1.1) was true.  This is, I believe, a text-book case of
> "equivocation".
 
I would take you up on this, if this were comp.std.c; but since I have
claimed above that your analogy is false, I see no point in discussing
it further here. (Actually, writing portable programs in C is _extremely
difficult_, so much so that most people don't try, and even when they do,
they usually fail. There is _no_ public-domain C software of any repute
that conforms 100% to ISO 9899, for example.)
 
> I see the same application of interpretations in Darrell's claim:
> (2.1) There are inherent qualities in SGML such that it is impossible
>  to design portable and application-program-independent SGML
>  documents.
> (2.2) There are inherent qualities in SGML such that it is possible to
>  design non-portable and application-program-dependent SGML
>  documents.
> Claim (2.1) is obviously false, and requires no further comment.
 
It at least requires a definition of `portable'. Any SGML document can
be broken down into its syntactic fragments, but does that make it
portable? If you were sent a program in a new language, a BNF grammar would
let you _see the structure_, but you would not _understand what it meant_.
 
I think Darrell's point is
 
"In practice, SGML does not sufficiently address the problems of
document portability _between applications_."
 
So proprietary document types, which have no meaning to general
document-processing applications, will not go away. The fact that the
application uses SGML as a transport mechanism may save work for the
application implementors, but it will not _necessarily_ make those
documents `open'. Thus SGML doesn't get _us_ anything, such as applications
which do useful things (searching, formatting, indexing) to _any_ document.
 
But maybe you are happy with this. In that case, isn't SGML just a
text-based alternative to ASN.1 BER?
--
Alasdair Grant                                      +44 223 334447
MVS Systems Group / Small Systems Integration Group
Computing Service
Pembroke St., Cambridge CB2 3QG, UK