I like the idea of Microformats — they’re essentially loosely standardized schemata with a strictly standardized syntax (which plays nice with (X)HTML — hence the “h” in front of hCard, the new groovy Microformat version of vCard). They’re 90% of the way to my new Nirvana of all-text interoperability (I no longer trust binary formats unless the readers and writers are Open Source and old).
But I hate angle brackets, and I hate having to do crap that the computer should be doing.
So, I’m defining Picoformats. It’s like this. You can do a pReview, or pCard, or pCalendar, or whatever — we’ll call it a pThing. If there’s a corresponding Microformat or other similar format defined, you SHOULD include the constituent fields that the format defines as required; if not, you SHOULD try and include the same fields when do you do the next pThing.
You SHOULD write in plain English, or whatever you like. You SHOULD write in the format you like, but you MUST NOT hand-code more markup than necessary, memorize any XML namespaces, or be tied to special-purpose tools.
You SHOULD prefix the constituent parts of your pThing schema with the name of the field, set apart in some reasonable way, like being the first thing on a newline before a comma, like this:
Name: Bob Smith
or with some easily-added formatting, like this:
Name Bob Smith
or whatever happens to work for you. You MUST NOT freak out if the word you use to represent the field is not exactly the same as in the corresponding schema, although it’s AWFUL NICE if you keep it real close (like “Date Reviewed” instead of “dtreviewed”).
You SHOULD keep all the schema fields in the same document, right up next to each other, and delimited in some easy to dig way like starting on newlines or something.
You MUST trust that Google and its heirs will help people find your pThing, and that smart people like Ana-Maria will help computers understand your pThing. You SHOULD help them both out by writing a parser to a standard format if it’s easy to do.
Now: to write a pReview or two.