From: Karl Anderson (kra@monkey.org)
Date: Thu Sep 28 2000 - 17:31:59 PDT
"Gavin Thomas Nicol" <gtn@ebt.com> writes:
> These types of situations come up *everywhere*. Look at the DOM
> spec for example, which is written is XML, but which produces HTML,
> JAVA/JavaScript/CORBA bindings, and also PS and PDF.
Two coworkers of mine are writing a book using StructuredText, which
is a way to encode simple relationships in a text document with
indentation, prefixes, etc., like we've all been doing for years on an
informal level - *emph*, "-" bullets for lists, indentation sublevels,
etc. They edit the text, it's stored in a DOM tree, and export it to
others as XML and HTML. They never have to touch the *ML unless
they're tweaking the display, not the structure, it's the DOM in the
center that bridges everything.
One of them uses it to make PowerPoint slides, too - DOM traverser
builds the slides by making COM calls, which is great, because when
writing he doesn't need to deal with all of the features that he
doesn't want to use.
> > 6) Finesse. Users demand a certain level of finesse for thier
> > applications... on the desktop, they all but demand involved
> > interfaces super-charged with DHTML and JavaScript.
>
> I understand your point... it makes maintenance much harder
> than you'd like. Here, the most important thing is the data.
> If the data is pretty generic (technical manuals etc.) you
> don't need the bells and whistles, and the payoffs are much
> higher.
I think that the farther out you can push the fancy schmancy stuff,
the easier maintenance will be. Providing that you can design well
enough so that the features can hang on the strucure but not pollute
it. XML can fail at that just as easily as any other format, but it
can succeed, too.
-- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/
This archive was generated by hypermail 2b29 : Thu Sep 28 2000 - 16:59:59 PDT