[TDP] Alternative to mark-up languages (was: On Tunes Distributed Publishing)

Tom Novelli tnovelli at gmail.com
Tue Mar 27 20:50:43 PDT 2007

Well, I've still got some reading to do, but I'm making some headway
on your latest contribution...

I liked the NetBook paper.  This line from the end sort of sums it up:
"Fragment theory provides the rationale for these facilities. Its
usefulness stems from its simplicity."  We've got to follow up on
Dennis Shasha's work...

Now, let's see if I understand your proposal:

1. Enter the data in plain text, e.g. "wiki text" or reStructuredText.
 Let the computer parse it automatically, tweak as necessary, classify
and index it.  Store the original text verbatim, with annotations as
pointers into the text.

2. Deal with _meaningful_ patterns in the text (don't do formatting/styling)

3. Think of "Fragments" rather than "Documents"

4. Use an advanced decentralized RDBMS.
(Not SQL... Is this relational Python thing, Dee, more helpful?)

That sounds like a good start.  #4 is a long way off, of course...


XML, I think, is a grey area.  It's cleaner and more flexible than
HTML, on one hand, but the markup format sucks.  Is that your only

I'm not seriously suggesting we store documents in XML, just use it as
a back-end for publishing.  But a good web-based XML editor could
cause me to think again.  After playing with MIDAS (Mozilla's
in-browser editor) for a few days, it seems to have too many
limitations right now.  If it can't produce clean XML, I don't want
it.  However, we may yet find a use for it, possibly in a future
version.  For example, maybe it can be made to display *bold* in bold
as you're typing it, the way EMACS can.


I'm not sold... I think it'll give you Carpal Tunnel Syndrome.  And
modality isn't necessarily evil.  Some great ideas too, of course.
It's a neat experiment.

The following covers some key points in TUNES, which should be more
prominent on our website:

> Archy dispenses with the concept of "applications" and prefer
> a much modular and consistent approach instead, sets of commands:
> you add and learn gradually each command you need.
> It offer true interoperability: your "content" is not segregated
> in application specific file formats.
> This avoid redundancies: no more 5 spell checkers, one is enough
> and is system-wide; no more dozens of micro-editors (fields in forms,
> for example) each with some functionality lacking. True fine-grain
> reuse: what O-O always promised and never really delivered
> (note the "fine-grain").
> Unfortunately developers do not understand that this (the tyranny of
> file formats) is *exactly* the reason for which DBMSs where invented
> and were using -- guess what -- XML! But this is changing, probably
> for performance problems, and they are moving toward...


> P.S.: Tom, I don't see how is possible to access old static
>       content pages from the home page. This definitely is
>       NOT acceptable.

I've added links to old content.  The old index.html is gone, but
sitemap.html is the real "portal" to the old site.  Let me know if I
missed anything else.

We need to keep our website looking fresh... Appearance is important.
 We discussed this about 6 months ago and there was a pretty clear
consensus: Just do something, it doesn't have to be perfect.


More information about the TUNES mailing list