bug-gne
[Top][All Lists]
Advanced

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

Re: [Bug-gnupedia] Re: Classification difficulty and incompletene ss


From: Mike Warren
Subject: Re: [Bug-gnupedia] Re: Classification difficulty and incompletene ss
Date: 18 Jan 2001 13:34:16 -0700
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko)

"Thomas E. Vaughan" <address@hidden> writes:

> I keep piping up about this because, if we are really serious, then
> we NEED to be able to support serious math content in the best
> possible way.  If each article must have only a single, unified
> <content> section that only supports a subset of HTML, then are we
> ruling out the possibility that an article might have several HTML
> nodes, as in the default output of latex2html?

No. The back-end representation need bear absolutely no resemblance to
what is presented to the user. If one wants nodes split up after every
title, then that can be easily accomplished.

> And how many HTML tags shall we support?

I would argue for ``none''. All we really need is <em> for emphasis.
Whether that results in bold, italic or a different font can be
decided later; the important information (that the author wants to
emphasize a certain section) is captured. Other examples one might
consider:

<reference>Winnie the Pooh</reference>

which would correspond to a later bibliographic reference of the same
title and be treated however it makes sense for the particular
medium. Any potential ambiguities could be resolved like so:
<reference id="1234">. When translated to PDF, this might be a
[1]-type reference to a later bibliography entry. For other types of
devices, it might be possible to do something quite different.

> I still don't know how MathML will fit into all of this.

If the DTD is designed correctly, it will be possible to embed a
MathML (or whatever is decided) formula directly into the content
section.

> In a previous message, I tried to bring up for discussion the issue
> of just replacing the <content> section with a URL to a page that
> the author provides.  At least at first, this would give scalability
> and reduce the central resource requirements.

Yet it makes the content almost useless, as all the content would be
in different formats. How could you go about producing a LaTeX
translater for such a mess? At least with a well-defined DTD, this
problem becomes possible (if still somewhat difficult).

-- 
address@hidden
<URL:http://www.mike-warren.com>
GPG: 0x579911BD :: 87F2 4D98 BDB0 0E90 EE2A  0CF9 1087 0884 5799 11BD



reply via email to

[Prev in Thread] Current Thread [Next in Thread]