[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Document Management



-----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 document 
formats, there certainly can only be one source format for each project. this 
is transformed into target formats as needed, pdf, html, plain text, audio, 
braille, just to name a few.

this entails that the source format has to be abstract, meaning it shall 
exclusively deal with document structure and shall not in the least express 
anything that has to do with how the target format represents the content, as 
we want to be able to transform the source into a multitude of targets, with 
a broad array of features and specific constraints. this precludes any 
wysiwyg, since it has to presume a very specific target representation. TeX 
is also not suitable because it does deal with graphical represenation. LaTeX 
could be adequate if restricted to document structuring commands, here the 
problem is that it readily mixes with TeX and all of its extensions, and so 
the user is always tempted to circumvent the abstraction requirement. html is 
probably not desireable either since its structuring primtives are rather 
weak and it is being overloaded with layout funtionality (cf. LaTeX). a 
custom set of xml tags would certainly be very attractive, but this would 
also require custom tools to transform into target formats.

ideally the mapping from source to target formats is performed 
programmatically using generally available software tools. one problem to be 
easily identified here is how to deal with figures, which can hardly be done 
without. they usually can not be automatically transformed into a textual 
description, as may be neccessary by some targets, the solution would be that 
the transformation software prompted the user to provide an adequate textual 
representation. 

lastly the source format has to be terse and easy to use, as to not overwhelm 
the user and prevent serious work.

what comes to mind as far as source formats best adhereing to the 
requirements set out is concerned are texinfo and docbook. the former though 
as i see it is deficient in image inclusion. as i understand this has to be 
done through target specific commands. the later on the other hand is might 
be too vast to be easily useable.

wait, what about unicode characters, i guess it would be tricky getting 
tengwar properly displayed  on an ascii terminal ;)

co'o mi'e .bjorn. 
- -- 
- -------------------------------------
b.gohla@gmx.de		Björn Gohla
pub  1024D/834F4976 2001-01-07 Björn Gohla (Wissenschaftler, Weltbürger) 
<b.gohla@gmx.de>
     Key fingerprint = 9FF4 FEDA CCDF DA0E 14D5  8129 6C14 3C39 834F 4976
sub  1024g/29571FE2 2001-01-07                        
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=
=68kP
-----END PGP SIGNATURE-----