[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bibulus-dev] Re: Math
From: |
Thomas M. Widmann |
Subject: |
Re: [Bibulus-dev] Re: Math |
Date: |
09 Apr 2003 21:04:48 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
"Torsten Bronger" <address@hidden> writes:
> address@hidden (Thomas M. Widmann) writes:
>
> > [...]
> >> Of course, the XML tools must be able to find the MathML DTD. I had
> >> problems with this point. Unless we have a counterpart for SGML's
> >> Catalog scheme, I put everything into one big file called
> >> hmml2dst.dtd and included it with
> >>
> >> <!ENTITY % MathML-and-HTML-distillated.dtd
> >> PUBLIC "-//Torsten Bronger//DTD MathML 2.0 distillated and
> >> HTML 4.0 entities//EN"
> >> "hmml2dst.dtd">
> >> %MathML-and-HTML-distillated.dtd;
> >>
> >> in my DTD.
> >
> > Doesn't that lead to copyright problems? What's the license for
> > the MathML DTD?
>
> Permission to use, copy, modify and distribute the XHTML 1.1 DTD and
> its accompanying documentation for any purpose and without fee is
> hereby granted in perpetuity, provided that the above copyright notice
> and this paragraph appear in all copies. The copyright holders make
> no representation about the suitability of the DTD for any
> purpose.
>
> You don't understand why it says "XHTML"? I don't understand it,
> too. The whole MathML DTD is a little bit sloppy.
OK, but at least we probably won't get into trouble for cutting out
the parts we need an including them. Good.
> >> Probably it's wise to switch to something like the following
> >>
> >> <!ENTITY % inline "(#PCDATA | b | i | t | math)*">
> >>
> >> for all inline content models eventually. Most DTDs do something
> >> like this. Alternatively, you can use the "mml:" namespace for
> >> math. It's possibly more secure, but I think it just makes typing
> >> more difficult.
> >
> > Indeed, but of course math is probably the exception in
> > bibliographies. Something to consider.
>
> Well, if you don't use it, you don't feel its presence in the DTD.
> But you're right, it should not distract you from creating the core
> of your DTD.
What I meant was that using the mml: namespace wouldn't be too bad
because it would get used relatively seldom, but that of course it
would be more convenient leaving it out.
But you're right too: This is something to think about later.
> >> > [...]
> >> >
> >> >> For LaTeX (or BibTeX), you have to convert it with e.g. XSLT. But
> >> >> this has been done already by numerous people.
> >> >
> >> > Has it? Do you have a reference? And is any implementation of it
> >> > released under the GNU license so that we can include it?
> >>
> >> I did it for my tbook DTD. But you have to extract the MathML code,
> >> I'm afraid.
> >
> > How difficult would that be, you think?
>
> Rough estimate: one weekend.
Thanks.
> >> The same is true for Casellas' db2latex at
> >> <http://db2latex.sf.net>. Gurari tried it, too, but it was not a
> >> very serious approach, just a test. However it shows how simple
> >> it can be basically. All three variants are very free, I think.
> >
> > OK. Which one would you recommend, given that Bibulus is written in
> > Perl? I'll try to find some time to read up on all three, but I don't
> > promise it'll be very soon.
>
> I don't know Perl. Is there an XSLT processor for Perl? I've never
> heard of one.
I just had a look in Google, at there is something called XML::XSLT.
However, it's incomplete. :-(
> Saxon and Xalan are Java, Xalan also in C++, xt is java. I'm afraid
> you would have to call an XSLT processor as an external application.
:-(
It's no big problem, of course, but it gets increasingly difficult to
obtain a working Bibulus if this is needed.
> But I've seen some examples of XML-->LaTeX conversion directly in
> Perl in a book (The LaTeX Web Companion by Goosens/Rahtz). It's not
> as elegant as in XSLT, but it works. However using this for MathML
> is totally new I think. You could not use existing code.
And so, it would take a lot of time. I'll definitely postpone this
for a while (unless you or somebody else wants to have a go at it).
> >> I regard my approach as the best one because it is the most
> >> complete. You need only a subset because only inline math is
> >> interesting in bibliographies I think.
> >
> > I agree. How much code are we talking about to handle inline math,
> > and is it in XSLT?
>
> It is XSLT code, and I would say 500 lines without comments.
It's not too bad. Even rewriting might be feasible in that case.
> > [...]
> >
> >> @MISC{tbook,
> >> title = "The {\sffamily \textbf{t}book} system for XML authoring",
> >> author = "Torsten Bronger",
> >> url = "http://tbookdtd.sourceforge.net",
> >> year = 2003,
> >> month = mar,
> >> }
> >
> > Very interesting. I very much like the idea. Do you recommend we use
> > tbook for Bibulus documentation?
>
> Yes, I even think that it's more useful than DocBook. But I think
> that texinfo is the best alternative. tbook is documented via
> texinfo, too.
OK. For the time being, I think the embedded Perl documentation (POD)
is fine, but if we want to write a real manual at some point, we might
want choose tbook.
> >> (And I'm still looking for a good BibTeX replacement in tbook. ;-))
> >
> > It certainly would be very easy to make an output module called
> > Bibulus::tbook which would output the bibliography in tbook XML.
>
> This is not necessary. I can import e.g. raw or cooked DocBook
> bibliographies, and maybe even the Bibulus XML file itself.
You know that better. But if you can use DocBook bibliographies, what
is it that you need for tbook?
/Thomas
--
\author{Thomas Widmann\thanks{3/2, 54 Mavisbank Gardens, Glasgow G51\,1HL,
Scotland, address@hidden Tel.~+44 (141) 419\,9872.}\\{\tt address@hidden