On Tue, Nov 18, 2003 at 10:12:31AM +0100, Lars Gullik Bjønnes spake thusly: > Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> | Does this more clearly illustrate the idea?
> >
> | Check-in later today, shout to object ;-)
>
> Object!
>
> I am all for cleaning up and parametization. But I am not quite sure
> what implications this will have. What I do not like (seemingly) is
> that docbook get it cleaned up, latex stays ugly. We need to have
> solutions that make the .layout format better and that works with all
> first-class output formats.
>
> How does this listitem stuff fit with LaTeX? Does it fit at all?
>
> --
> Lgb
It appears this requires a more explicit explanation (bend a model in
iron wire, as we say over here). So here is for your edification :) a
patch containing not only the changes I made, but also the agu-dtd
document class that I am preparing to support the AGU XML format. This
stuff is sort-of working, but still very incomplete.
You see, the main difference between LaTeX and XML is, that while
LaTeX is a (one!) mark-up language, XML is a meta-language or
'language construction kit'. (So when Microsoft say that their Office
formats will be XML based, that means next to nothing :)
This means that, whereas LaTeX has lots of add-on packages, the core
language is pretty fixed. This is why the hard-wired stuff for
item-environments works without much parametrization. Also LaTeX is
much less verbose with its mark-up than most XML dialects.
Though I have said earlier that the AGU format is a variant of
DocBook, the differences in syntax between original DocBook and
AGU DTD are massive compared to what you can find between any two
LaTeX document classes.
If you compare these two XML formats for item-environments, you see
---
<itemizedlist>
<listitem><para>
The catalog.jar and catalog-apps.jar paths, used during the
configuration step.
</para></listitem>
<listitem><para>
The java archives used by the XSLT, if the XSLT used is a java one.
</para></listitem>
</itemizedlist>
---
for an 'itemize' layout list in DocBook. For AGU it becomes
---
<lst type="bulleted">
<item><p>
The catalog.jar and catalog-apps.jar paths, used during the
configuration step.
</p></item>
<item><p>
The java archives used by the XSLT, if the XSLT used is a java one.
</p></item>
</lst>
---
You see that pretty much everything that *can* be different, *is*
different. I don't think that three added parameters in the .layout
file format is too high a price to pay to describe this. They are all
three syntactically meaningful. But really I see no way to make them
useful for the LaTeX side of things. There they are just a solution
looking for a problem. (Yes, I did look at it. See output_latex.C
patch :)
There is of course the alternative of adding a new XML output type in
addition to linuxdoc and docbook (which I think BTW we should at some
point try to merge). Disadvantages are massive code duplication with
the associated maintenance load, and doing nothing to ease the job for
other people wanting to add their XML document classes by writing a
set of .layout files, no coding required. We should open up our
architecture!
As you will also see when reading the patch, finally latexparam is
used (more) consistently, not just as a jack-of-all-trades to shore up
the shortcomings of the .layout format for describing XML document
classes.
(BTW I am amazed that José got this stuff to work as well as it does,
given the still extremely LaTeX-centric architecture of both the LyX
core and the .layout file syntax! XML *is* really very different from
LaTeX and IMHO it is time to take that into account realistically.
Without fragmenting LyX of course, there I agree.)
As for docbook being cleaned up and latex being ugly, I don't agree.
This mistaken appearance comes from docbook being still very
incomplete, while latex is mature. In fact the docbook code is *still*
pretty ugly as a workaround for LyX architectural limitations, and
what I did, didn't actually touch the ugliness at all.
I hope this clears up things a bit.
Hoping for one (or more) of three outcomes:
1) a serious in-depth discussion
2) go-ahead for checking this in (with or without the AGU stuff)
3) clear (and realistic, finite-execution-time :) instructions as to
what to change/do differently in order to make this check-inable.
- Martin
y.diff.gz
Description: application/gunzip
pgp00000.pgp
Description: PGP signature
