Re: Re: Math

"Torsten Bronger" <[email protected]> writes:

> [email protected] (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, EU\@. Tel.~+44 (141) 419\,9872.}\\{\tt [email protected]}}