> Yes, converting is what I was thinking about. I don't know how > important the fullness of the markup is -- TWiki, for instance, might be > too full. We don't need to cover every kind of layout -- tables, > definition lists, etc. -- just the ones that are typical and > unambiguous.
That might be the questions: what is really essential? If you ask ten people you might get ten different answers :-) > That's what I was thinking about with reversable translations -- > translating the XML (XHTML-based) markup into other kinds of markup, and > back again. The problem with many Wiki markups is the canonical form is > plain text, and so the WYSIWYG editor and the text editor will clash. > TWiki-like markup might actually be fine, since it accepts HTML in > addition to other kinds of markup. The original Wiki markup wasn't as > rich as HTML (and didn't allow embedding), so it wouldn't be > appropriate. But this is only a problem if you see HTML (I hope you ment HTML editor if you said WYSIWYG editor) as the "main" format. I'd rather discourage the use of html tags in the text, since this leads to the kind of problems XML/XSLT went out to addess. It's easier though to allow well known tags... > In terms of reversability, it only matters that when you translate from > XML to text markup, and then back to XML markup, it should be > XML-equivalent (so whitespace don't matter much, among other things). A > good translator would have to use heuristics to figure out where > text-markup is helpful and where it's easiest to leave the XML markup. > The current translator only changes Wiki links to be format > ted with > []'s, and <p> to be \n\n, which probably covers nearly 50% of the usage > (by volume). Bold, italic, and other simple markup would probably cover > another 25%. With lists and a couple other structural markups, you'd > have most of the rest, I'd think. Things like the table support in > TWiki didn't impress me -- it was like learning tables all over again, > except I learned about HTML tables for other reasons a long time ago and > I'd rather just use that knowledge. I thought that TWiki tables are quite elegant :-) > Then there's non-XHTML markup... the Wiki links are the first such > markup, but other's would probably come along. MoinMoin and TWiki have > a ton of them, where the original Wiki only has the Wiki links... I > don't know where to draw the line. At some point those Wikis are taking > the place of an application framework, but we already have an > application framework so we don't need to do that. That's maybe just the point: if we have a look at TWiki, it's - an application framework - a document management system (for one sort of documents) - a special markup language (html shorthand) We have already the application framework (o.k. parts of what is needed) but we are missing the other parts. If we had some basic document management system, we only needed to define some document format for the wiki pages and provide the handlers for that format. In this fashion, we could even have different document format within the same wiki. The only thing that has to be the same is the linking mechanism. I just realised that this sounds like quite a large project :-) > But there are some > really cool ones... like TWiki has one where you can embed LaTeX math > expressions, and it will inline an image of that expression. I don't > write many math expressions, but if I did I'm sure I'd fall in love with > that. That makes sense, too... but embedding an RSS feed of slashdot > seems more superfluous. Maybe if it's properly modular it won't matter. Apropo LaTeX. I always thought that LaTeX is much easier to write with a text editor than XML/HTML/SGML. Maybe one should think about using a subset of LaTeX. > Ian Stephan ------------------------------------------------------- _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
