Tartan: wiki-text parser

Tartan is a general purpose text parsing engine whose main target is
wiki text parsing. It doesn’t implement one specific mark-up, but
instead, provides a way to specify a variety of mark-ups. So, Tartan is
a bit more “involved” than a purpose built parser like RedCloth
http://whytheluckystiff.net/ruby/redcloth/ or BlueCloth
http://www.deveiate.org/projects/BlueCloth, but provides the following
benefits:

  1. separates the specific wiki syntax specification from the
    implementation
  2. allows layering and extension of parsing rules
  3. allows multiple output formats from the same syntax specification

The current implementation of Tartan is in Ruby and includes a full
Markdown http://daringfireball.net/projects/markdown/ parser
(described in YAML). The format of the parsing specification has been
created with an eye to having a language independent definition of wiki
(and possibly other) mark-ups. That’s a lofty goal, and Tartan hasn’t
quite gotten there yet, but we think there’s a clear path. In any case,
even if it is only available in Ruby it will hopefully be helpful for
projects needing to do something more than just convert wiki text
directly into HTML.

RubyForge project page: http://rubyforge.org/projects/tartan/


OK, that’s the project blurb. It’s been available on RubyForge for a
while (http://rubyforge.org/projects/tartan/), but I’ve been sidetracked
on some other projects and am just now getting some time to work on it
again.

The project was started several months ago as part of Informl
(http://rubyforge.org/projects/informl/). It was a pretty big project
to bite off for me as a fairly newby Ruby programmer, but, hey, I leaned
a lot about Ruby and still have a lot to learn.

So, if you think the project is interesting, let me know (and if you
think it’s stupid, I guess I’d like to know that too…). I’d really
like to get feedback on the project at all levels. If you have the
stomach to read the code and provide some (kindly) feedback, that would
be great – there’s a lot of room for improvement.

I’m currently working on creating a (hopefully) coherent name space for
the library and the parsing extensions, which will probably require a
fair bit of interface change, so don’t get too comfortable with the
current API…