XML email, was: Re: HTML email

Date view Thread view Subject view Author view

From: Stephen Williams (sdw@lig.net)
Date: Fri Jan 19 2001 - 09:01:44 PST


Eugene.Leitl@lrz.uni-muenchen.de wrote:

> Lucas Gonze wrote:
> >
> > I think it's pretty ballsy of JB III. to question the dogma against HTML
> > email. Come to think of it, I think he's absolutely right. Why shouldn't
>
> Especially ballsy, since he gave no (as in zero, zilch) hard reasons why
> HTML should be preferred against plain text. Given the well-known reasons
> why we shouldn't, he's perhaps showing more foolishness than testicular
> fortitude.

HTML is questionable in many circumstances, but XML would make a lot of sense.
The markup could be used both as meta-subtextual clarification and as a means to
provide great search and filtering ability. The tags could be added by hand or
with GUI help.

I consulted at Lexis (formerly Lexis-Nexis, formerly Mead Data Central) for over
3 years. They get feeds from just about every published data and legal source
available. They then convert or add tags that indicate part-of-document.
Things like title, author, person, place, (legal) cite, etc.

Fancy rendering, not needed for email but sometimes desirable by the sender,
could then be transcoded from XML in the standard ways (XSL, etc.).

> > Pine be able to launch lynx in-place? At this point in time, is there any
> > environment without an HTML renderer?
>
> Look, the point is not what we *can* do, but what we *should* do.
> I *can* poke a screwdriver into my eye socket, but this doesn't mean
> I *have* to.
>
> > The existence of web bugs is not, in my humble but cocky opinion, a
> > serious problem. It is really really easy to fix.
>
> It is not a serious problem, compared to the other ones. As to the easy
> fixes, please tell us, because I don't see a quick and easy solution.
> If you allow remote resource access while the rich content is rendered,
> you're toast.

A glaring problem has always been that there was no standard way to package HTML
and referenced items like images in a single container. This is handled
elegantly in a different context by QT, and various solutions have been proposed
but nothing has progressed to standard that I know about. Pointers?

Even with the availability of such packaging, it wouldn't always be desirable.
Web bugs are a difficult problem to solve generally if the information content
in the reference images etc. is important.

sdw


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Jan 20 2001 - 04:44:58 PST