Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Sat, 19 Jul 2003 16:16:23 +0200 Received: by mail.proteosys.com (8.12.9/8.12.2) with ESMTP id h6JEGKSb007765 for ; Sat, 19 Jul 2003 16:16:21 +0200 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.9/8.12.9) with ESMTP id h6JE0ump000245; Sat, 19 Jul 2003 16:00:56 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C34E00.55071580" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h6IM06T9023367; Sat, 19 Jul 2003 15:58:58 +0200 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 0709 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Sat, 19 Jul 2003 15:58:58 +0200 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h6JDwwM9027361 for ; Sat, 19 Jul 2003 15:58:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by relay.uni-heidelberg.de (8.12.9/8.12.9) with SMTP id h6JDwvmp000095 for ; Sat, 19 Jul 2003 15:58:57 +0200 (MET DST) Received: (qmail 4413 invoked by uid 65534); 19 Jul 2003 13:58:56 -0000 Received: from p3EE015AF.dip.t-dialin.net (EHLO wilson.rwth-aachen.de) (62.224.21.175) by mail.gmx.net (mp025) with SMTP; 19 Jul 2003 15:58:56 +0200 In-Reply-To: <16153.14658.292643.77990@pussy.npc.de> (Joachim Schrod's message of "Sat, 19 Jul 2003 14:27:46 +0200") Organization: Aachen University of Technology (RWTH) References: <20030710081528.A12401@diabolo.informatik.rwth-aachen.de> <78ADDA01-B2DC-11D7-8AE7-0050E4455404@atlis.com> <20030711081704.A14039@diabolo.informatik.rwth-aachen.de> <16146.60345.852158.31606@pussy.npc.de> <16150.44860.510973.820690@pussy.npc.de> <200307171432.h6HEWXrZ002742@bilbo.localnet> <16151.19056.880153.478641@pussy.npc.de> <200307182058.h6IKwHwi028465@bilbo.localnet> <16153.14658.292643.77990@pussy.npc.de> Return-Path: X-OriginalArrivalTime: 19 Jul 2003 14:16:23.0307 (UTC) FILETIME=[5535EDB0:01C34E00] User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) X-Accept-Language: de, en X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) x-pgp-fingerprint: CA13 274E 96EF 1DB1 4992 D7D4 D523 14FB 4752 F2EF X-Face: $:ZH*7V$(*!W]7{qQLhM-f#d(Q6#shsBz8[qPwvRr(Hy{#Y3-$C\85(LKA[4'=X]Jy\),51 DU?fMKf}G[2r)>~K8Z3dWD<'R/hRsgW>Q.Fytf-:n*FG&iWyWNMM+c)(_R.k`$zrcq5%9yt"cd)Q]c 5G_W!:/8\S4ytn&NYP,OVd_|*GjEqvk:zK(,BTXvqgj4 X-Spam-Score: -32.8 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA x-binford: 6100 (more power) x-pgp-affinity: will accept encrypted message for GPG X-Home-Page: http://www.wikipedia.org/wiki/User:Bronger Content-class: urn:content-classes:message Subject: Re: XML vs. (La)TeX markup Date: Sat, 19 Jul 2003 14:54:41 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: XML vs. (La)TeX markup Thread-Index: AcNOAFVZZsFo6mSYS4OFCKUL/4Ikug== From: "Torsten Bronger" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4721 This is a multi-part message in MIME format. ------_=_NextPart_001_01C34E00.55071580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Halloechen! Joachim Schrod writes: >>>>>> "TB" =3D=3D Torsten Bronger = writes: > > TB> It's very very difficult to parse arbitrary TeX. > > I differ here, about the "very very". For one, there exist parsers. > Second, a professional versed in formal languages and compiler writing > can create a new TeX parser from scratch in 2-4 weeks. It is difficult > not because of technical reasons but because existing programs are not > put into real end-user products -- the demand doesn't seem to be > there. But the authors need a certain amount of discipline, and there I see the problem. My own thesis included 10--20 packages and used many of their commands, which must be parsed too. > [...] > > TB> I think eventually we won't actually see XML anymore. We will use > TB> e.g. systems like LyX that use XML as the underlying format, and > TB> that call TeX for decent typesetting. XML is not for the human eye > TB> in my opinion. > > TB> Until then, you can make XML rather bearable. Joachim's problems > TB> with micro-typography, space handling, and TeX markup in special > TB> situations (in particular in formulae) can be dealt with in XML > TB> applications. > > I keep reading that argument for almost 15 years now, since I started > to work with SGML. This statement was taken over unaltered by the XML > fork. Yes, "XML is not for the human eye" -- and why are we forced to > work with it that way? Because systems like LyX haven't got so far yet, and systems like OpenOffice still must prove that they are suitable for this task. > The problem is not "can it be dealt with". The problem is "it is not > dealt with". Lots of promises about tools that are elementary to the > approach, since the markup is not to be meant to be written by humans. > But no strong progress. Where is the Apache XML project to provide a > good interactive document input and manipulation facility? General XML editors are not very interesting in my opinion. To be honest, Emacs is sufficient for me. The intersting thing are editors for *special* XML applications. Let me dream a bit: All scientific publishers agree on an XML format and order a simple-to-use GUI program that can create these documents. It runs on Linux, Windows, Mac, etc (because it's simple itself). Authors can download it and write their articles with it. Then there are no authors anymore that use exotic file formats, format their text in a very strange way, no employees of the publishers have to re-type the articles, authors don't lose time with superfluous typographical fine tuning, guideline can be made much simpler, archiving and retrieving is much simpler etc. The reason why such things are not realised are probably rather complex. I've seen only one DTD so far that tried something like that, and my impression was that the creators were not competent enough. Moreover one publisher alone would never dare such a thing. Tschoe, Torsten. -- Torsten Bronger, aquisgrana, europa vetus ------_=_NextPart_001_01C34E00.55071580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: XML vs. (La)TeX markup

Halloechen!

Joachim Schrod <jschrod@ACM.ORG> writes:

>>>>>> "TB" =3D=3D Torsten = Bronger <bronger@PHYSIK.RWTH-AACHEN.DE> writes:
>
> TB> It's very very difficult to parse = arbitrary TeX.
>
> I differ here, about the "very very". = For one, there exist parsers.
> Second, a professional versed in formal = languages and compiler writing
> can create a new TeX parser from scratch in 2-4 = weeks. It is difficult
> not because of technical reasons but because = existing programs are not
> put into real end-user products -- the demand = doesn't seem to be
> there.

But the authors need a certain amount of discipline, = and there I see
the problem.  My own thesis included 10--20 = packages and used many
of their commands, which must be parsed too.

> [...]
>
> TB> I think eventually we won't actually see = XML anymore. We will use
> TB> e.g. systems like LyX that use XML as the = underlying format, and
> TB> that call TeX for decent typesetting. XML = is not for the human eye
> TB> in my opinion.
>
> TB> Until then, you can make XML rather = bearable. Joachim's problems
> TB> with micro-typography, space handling, = and TeX markup in special
> TB> situations (in particular in formulae) = can be dealt with in XML
> TB> applications.
>
> I keep reading that argument for almost 15 years = now, since I started
> to work with SGML. This statement was taken over = unaltered by the XML
> fork. Yes, "XML is not for the human = eye" -- and why are we forced to
> work with it that way?

Because systems like LyX haven't got so far yet, and = systems like
OpenOffice still must prove that they are suitable = for this task.

> The problem is not "can it be dealt = with". The problem is "it is not
> dealt with". Lots of promises about tools = that are elementary to the
> approach, since the markup is not to be meant to = be written by humans.
> But no strong progress. Where is the Apache XML = project to provide a
> good interactive document input and manipulation = facility?

General XML editors are not very interesting in my = opinion.  To be
honest, Emacs is sufficient for me.

The intersting thing are editors for *special* XML = applications.
Let me dream a bit: All scientific publishers agree = on an XML format
and order a simple-to-use GUI program that can create = these
documents.  It runs on Linux, Windows, Mac, etc = (because it's simple
itself).  Authors can download it and write = their articles with it.

Then there are no authors anymore that use exotic file = formats,
format their text in a very strange way, no employees = of the
publishers have to re-type the articles, authors = don't lose time
with superfluous typographical fine tuning, guideline = can be made
much simpler, archiving and retrieving is much = simpler etc.

The reason why such things are not realised are = probably rather
complex.  I've seen only one DTD so far that = tried something like
that, and my impression was that the creators were = not competent
enough.  Moreover one publisher alone would = never dare such a thing.

Tschoe,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

------_=_NextPart_001_01C34E00.55071580--