Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

blazar (7356)

  (email not shown publicly)
Yahoo! ID: bik.mido (Add User, Send Message)

Journal of blazar (7356)

Sunday November 26, 2006
06:11 AM

Lightweight Markup Languages

[ #31716 ]

Shameless self ad for a node of mine at PerlMonks, and possibly not an extremely smart one, since it was not particularly well received, most probably due to the fact of being largely OT wrt the thread in which I posted it. In fact it was not received particularly badly either, rather mostly ignored. Indeed it's a meditation of mine I've been wanting to expose publicly for some time. So I'm pasting it literally here:

Hmmm, it seems I've mentioned YAML quite often lately. (Although I'm not really sure whether two entries count as "quite often" even if so close in time.) Now, it may seem OT to mention it in this thread too. But your points gave me the chance to expose a meditation that's been in my head for some time now. Now, both YAML and POD are LWMLs. As it happens, LWMLs are typically divided in two categories of which each of them is part respectively: namely, data serialization oriented and presentation oriented ones.

XML, for example, is suitable both for presentation and data serialization. But it sure is not lightweight. Now, I'm not really asking about merging (something based on) POD with (something based on) YAML. But I'd be interested in the feasability of an actual lightweight markup that could be suitable both for presentation and for data serialization. A first remark that one may make is that there are good reasons to keep logically different things, ehm, different. But it's also true that document description involves very similar issues to those that one can find in data serialization, e.g. wrt sectional divisions or special lists and many other things. So solving the problem once may be enough. Solving it in a way that is both forgiving enough for one task, and precise enough for the other IMHO would mean to achieve flexibility and reliability. Provided that it's possible, but then that's why I'm asking here...

I'd still be interested in the feasability of a markup language that is

  1. (as) lightweight (as possible);
  2. suitable for data serialization;
  3. suitable for document description.

Of course this has nothing to do strictly with Perl, but it would be nice if it had, one way or another. Not that I'm proposing this non-existing beast as a substitute for POD. (Actually, Damian's interventions in the above mentioned thread are quite instructive.)

I have my own ideas on the subject, but I have no working experience with it so I'd be glad to hear other people's opinions...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Hey, XML sure is lightweight compared to SGML!
    • If you read the respective specs, you’ll find it’s also quite lightweight compared to YAML.

  • POD always (still) sticks in the craw.

    I understand I have to learn a programming language to speak to a computer, but not that I need to learn a mark up language to speak to a human.

    I have a POD-learning block. I always cut and paste, or I have to go round finding out how to do it.

    How are the POD dialects going to work?
    • I understand I have to learn a programming language to speak to a computer, but not that I need to learn a mark up language to speak to a human.

      Well, it's not exactly to speak but to write, which is a related but different thing. And writing itself can have many different "incarnations" depending on one's actual aim. In this case, for example it's to document (Perl code) which is a slightly specialized form of writing as opposed to generic one.

      I have a POD-learning block. I always cut and paste, or I

      -- # This prints: Just another Perl hacker, seek DATA,15,0 and print q... ; __END__