Lists Home |
Date Index |
- From: Marcelo Cantos <email@example.com>
- To: firstname.lastname@example.org
- Date: Sun, 21 Mar 1999 14:22:05 +1100
On Thu, Mar 18, 1999 at 08:52:24PM -0600, Paul Prescod wrote:
> Richard Goerwitz wrote:
> > I come from a small shop that does a lot of SGML work. Trust me: SGML
> > is complex and intractable.
> This is way off topic but I must admit that these characterizations really
> annoy me.
> I can only speak anecdotally: I started using SGML while working for a
> professor of English as an undergrad. A single programmer (not me) wrote a
> pretty sophisticated application that converted SGML to HTML and RTF in a
> couple of months -- almost exactly the same amount of time it would take
> to do the same for XML. The process was almost identical too: you use a
> parser from James Clark, pump the data into your favorite scripting
> language and output it in the other language. The complexity of the input
> syntax was and is irrelevant to solving that problem.
> If we were doing that now it would be much, much easier because we would
> use Jade. That proves that technology improves and it becomes easier to do
> hard things over time which is pretty much unrelated to the distinction
> between SGML and XML.
There is a very well known phrase: "Nothing is worth more than what
people will pay for it." Paul here is essentially saying the same
thing: "Nothing is more complex than the amount effort it takes to
build and use it."
The perceived complexity of SGML is not dependent on how complex it is
to implement an SGML parser, since one already exists. What matters
is how complex it is to use. If one were to insist on considering the
underlying technology in determining the complexity one would be
forced to concede that a hello world program written in C is
enormously complex since it involves compilers, file systems, advanced
virtual memory architectures, windowing systems, possibly network
based windowing protocols such as X, virtual machines, OS kernels and
much, much more, in order to convert the contents of a C source file
into a pattern of light and dark phosphors on a CRT.
[The obvious caveat is if one cannot use the available technology for
whatever reasons. In this case, implementing the subsystem is clearly
part of the cost. In the case of SP, however, very few people will
have reason to do their own work: SP is free and usable in commercial
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)