Non-reversable transformations

Jay Allen: In fact, these days, there are tools and plugins that make this a bit easier like wiki formatting, Textile and, most recently, Markdown.  So what’s not to like? Why don’t I personally use one? Because of lock-in.

Thats the same reason I don't use them -- but what good alternatives are there, short of GUI HTML editors and the like.

So how can we make something that we're not locked into the format?

Posted by Eric Vitiello at
I fail to see the lock-in. I use Textile, and my the pages generated from that actually have better markup than what I'd usually write manually (because it's far easier to fuck up HTML than Textile). So I can either migrate the generated HTML, or build something trivial (using the Textile code-base, or starting from scratch) to move to some other format.

Posted by Stefan Tilkov at
The WikiText or whatever is essentially just a UI tool, the only lock-in is that you might get used to a particular syntax. Very like you might get used to a particular set of keyboard shortcuts. Whether or not the data is stored in this format is a separate issue. There are currently efforts underway to use XHTML as a vehicle for Wiki interop (until Atom's ready ;-)
See also : [link]

Posted by Danny at
I fail to see the lock-in as well. All of the formats are open and the transformation scripts (aka the «plug-ins») are open as well, so it's not impossible to hack your way to a Markdown-to-Textile-transformation and the like. It's not easy, but it's not like saving a document in a Microsoft Word binary or some other proprietary format.

Posted by Asbjørn Ulsberg at

I use Markdown to create XHTML. If I ever decide to stop using Markdown, I'll simply export my Markdown entries to XHTML and replace the old Markdown text with the XHTML output.

Like Danny says, Markdown (for instance) is mostly just a writing UI tool. The transformation source code is free software, and it is possible (pretty much by definition) to transform text written with Markdown syntax into clean XHTML code, so there is no real lock-in going on - just convenience.

P.S. I'd still love to see Markdown implemented as an import filter.

Posted by Már at

I think the point is that there may be more than one markups resulting in the same final xhtml. I dont know all the possibilities for markdown languages, but it seems that simplicity of format and uniqueness are opposing goals, for the most part.

Wiki's have the great notions of versioning and forward linking, but despite this, they havent caught on in companies at the non-developer level. I'd suggest that whats happened here is in fact an effect of markdown..if the forward linking and versioning was kept orthogonal to the markup, wiki's would see more uptake. For example, a wysiwyg editor control could be used instead or wysiwyg text was fed as an upload or via a RESTian web service.

Posted by Rahul Dave at

Rahul Dave - I agree about the orthogonality (in fact I made a start on a WYSIWYG editor for my bit of Wiki code, with XHTML as the persisted format). The RESTian services will hopefully follow the use of XHTML as an interop format.

Posted by Danny at
Danny, sounds great! Which wiki are you using? Would love to get the proffies here using such a system..

Posted by Rahul Dave at
Many many many people have responded and pointed out the error in my ways.  I am now testing out Markdown.  Thanks for all of your enlightened replies.  Now I feel like an idiot. :)

Posted by Jay Allen at

Rahul: A problem with

..if the forward linking and versioning was kept orthogonal to the
markup, wiki's would see more uptake.

is that diffs (which are great in relation to versioning) don't make a lot of sense in xhtml markups, while they do in wiki or plain text markups. And diffs are key, IMO, for versioning to be useful.

Posted by Santiago Gala at

Add your comment












Nav Bar