From b.gohla@gmx.de Wed Mar 28 15:32:05 2001 Return-Path: X-Sender: b.gohla@gmx.de X-Apparently-To: lojban@yahoogroups.com Received: (EGP: mail-7_0_4); 28 Mar 2001 23:32:05 -0000 Received: (qmail 15941 invoked from network); 28 Mar 2001 23:32:05 -0000 Received: from unknown (10.1.10.27) by l7.egroups.com with QMQP; 28 Mar 2001 23:32:05 -0000 Received: from unknown (HELO mail.gmx.net) (194.221.183.20) by mta2 with SMTP; 28 Mar 2001 23:32:04 -0000 Received: (qmail 13937 invoked by uid 0); 28 Mar 2001 23:31:47 -0000 Received: from a49f1.pppool.de (HELO linux) (213.6.73.241) by mail.gmx.net (mail06) with SMTP; 28 Mar 2001 23:31:47 -0000 Content-Type: text/plain; charset="utf-8" Reply-To: b.gohla@gmx.de Organization: private site To: lojban@yahoogroups.com Subject: Document Management Date: Thu, 29 Mar 2001 00:46:25 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01032900462501.00662@linux> Content-Transfer-Encoding: quoted-printable From: =?utf-8?q?Bj=C3=B6rn=20Gohla?= -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 coi rodo despite the risk of this being redundant: recognising that there most likely will never be total agreement on documen= t=20 formats, there certainly can only be one source format for each project. th= is=20 is transformed into target formats as needed, pdf, html, plain text, audio,= =20 braille, just to name a few. this entails that the source format has to be abstract, meaning it shall=20 exclusively deal with document structure and shall not in the least express= =20 anything that has to do with how the target format represents the content, = as=20 we want to be able to transform the source into a multitude of targets, wit= h=20 a broad array of features and specific constraints. this precludes any=20 wysiwyg, since it has to presume a very specific target representation. TeX= =20 is also not suitable because it does deal with graphical represenation. LaT= eX=20 could be adequate if restricted to document structuring commands, here the= =20 problem is that it readily mixes with TeX and all of its extensions, and so= =20 the user is always tempted to circumvent the abstraction requirement. html = is=20 probably not desireable either since its structuring primtives are rather=20 weak and it is being overloaded with layout funtionality (cf. LaTeX). a=20 custom set of xml tags would certainly be very attractive, but this would=20 also require custom tools to transform into target formats. ideally the mapping from source to target formats is performed=20 programmatically using generally available software tools. one problem to b= e=20 easily identified here is how to deal with figures, which can hardly be don= e=20 without. they usually can not be automatically transformed into a textual=20 description, as may be neccessary by some targets, the solution would be th= at=20 the transformation software prompted the user to provide an adequate textua= l=20 representation.=20 lastly the source format has to be terse and easy to use, as to not overwhe= lm=20 the user and prevent serious work. what comes to mind as far as source formats best adhereing to the=20 requirements set out is concerned are texinfo and docbook. the former thoug= h=20 as i see it is deficient in image inclusion. as i understand this has to be= =20 done through target specific commands. the later on the other hand is might= =20 be too vast to be easily useable. wait, what about unicode characters, i guess it would be tricky getting=20 tengwar properly displayed on an ascii terminal ;) co'o mi'e .bjorn.=20 - --=20 - ------------------------------------- b.gohla@gmx.de Bj=C3=B6rn Gohla pub 1024D/834F4976 2001-01-07 Bj=C3=B6rn Gohla (Wissenschaftler, Weltb=C3= =BCrger)=20 Key fingerprint =3D 9FF4 FEDA CCDF DA0E 14D5 8129 6C14 3C39 834F 4976 sub 1024g/29571FE2 2001-01-07 = =20 guard your privacy -- use GnuPG -- see: http://www.gnupg.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6wmnIbBQ8OYNPSXYRAuKyAKCTGZxctksIwKYfFwjrK3Hn6U5tUACgllH7 3rNT2Miw/K8SZvKlpYLTNeg=3D =3D68kP -----END PGP SIGNATURE-----