[Home]WikiMarkupStandardWorkingGroup

MeatballWiki | RecentChanges | Random Page | Indices | Categories
To take the discussions about a WikiMarkupStandard further a mailing list is on the rise:

This effort happens outside of the IETF; forming a WorkingGroup? was rejected there, because it's only about a file format. Btw, discussions about a WikiInterchangeFormat (IWML) and the WikiXmlDtd don't take place here, this was effectively postponed (such an effort should happen somewhere else, or afterwards).

This page is PrimarilyPublicDomain.

I just declared this page PPD October 5, 2004 to be proactive. If someone objects, we can change it. As we're talking about a standard, it may be better to use the IETF copyright rules rather than PPD. Any thoughts? -- SunirShah

1. Goals
2. Procedure
2.1. Why an RFC?
2.2. Invitations
2.3. Points Which Have Been Agreed Upon
2.4. Things to Consider
3. General Decisions
3.1. Decision Process
3.2. What kind of Standard
3.2.1. Single Markup Standard
3.2.2. Describe what we have
3.2.3. All in One
3.2.4. Senseful recommendation
3.3. What to Standardize
3.4. Level of Detail
3.5. Design Goals
3.6. Markup Family
4. Design Decisions
4.1. SGML/XML tags
4.2. Line-based Markup
4.3. Text Formats
4.4. Mark-up Guidelines
4.5. What to Avoid
5. Markup Elements
6. Universal Markup Rules

1. Goals

Forcing the opinion of a few onto all existing WikiEngines isn't the goal, but this effort should at least harmonize the basics, so users can more easily switch between sites and different systems.

It however seems senseful to write an InternetDraft?/RFC from any negotiated markup, registering for the "text/wiki" MIME media type. Future implementations may benefit from this, and the use of this text format could be extended beyond WikiWikiWeb systems; onto EMail for example.

2. Procedure

(That's very open to discussion as well.)

2.1. Why an RFC?

Pros:

Cons:

What about getting some work done first and decide then what we do with what we got?

2.2. Invitations

Who has already been contacted to take part in our discussions?

Who should be contacted as well:

Other wiki engines from Wiki:WikiEnginePopularity - not yet contacted:

2.3. Points Which Have Been Agreed Upon

Nothing yet.

2.4. Things to Consider

Feel free to add notes here, this is a WishList?.

Previous Discussion (moved from WikiMarkupStandard page)

A Wiki page might not be the best place to take this all forward. I therefore recommend that we negotiate with the InternetEngineeringTaskForce and start an official WG and a mailing list over there. The actual goals must be clearified (only recommend one markup, or simply mention the best plus all allowed variations). Also finally this would end in a RFC and something like a WikiTextMimeType. What's needed to get there:

There is a lot of experienced people over at the IETF, many of them already use Wikis in one form or another. Right now they aren't involved in this discussion, which would clearly benefit from the broader publicity an IETF WG provides. -- MarioSalzer?

I'd be happy to take part in such a process. -- SunirShah

It could take up to two weeks, before this gets approved. But I think an official IETF mailing list is a good thing, and it's worth the time waiting for it. Wether we also get a real WG is beyond me, but maybe this point isn't all too important anyhow (we could exceptionally write our InternetDraft?/RFC openly, instead of assigning only two or three editors). -- MarioSalzer?

I agree that it would be fun to do a wiki way standards process again (e.g. ModWiki). Do you want to lead the IETF process, Mario? -- SunirShah

Actually I've already sent out a request for forming a working group with me as proposed chair. Suddenly I have little experience in that role (and WGs in general), and because the rules of the IETF Applications area seem to be a bit stricter, I'd feel better if someone else could take this place (at least as second chair)! Even though there is the risk that they reject it because of this, we still should reach for a general MailingList. If the IETF doesn't give us one, I'd say we simply go to http://freelists.org/ (good experiences) then. Having a WG and producing a RFC are two distinct things anyhow. -- MarioSalzer?

I am more than happy to be the second chair if you'd like and help you with the process. It's not that scary to run a working group. It'll be a fun experience if you're never done such a thing before. The more difficult part will be convincing people there is a less superficial way of resolving the problem that choosing what punctuation to use, but that is something I will contribute as a member of the group, not as a chair. -- SunirShah

Of course I'm even happier if you take that role! But beware, that generally its advised against that a chair also is an official document editor. We're probably working a bit differently than any other IETF WG, but shouldn't admit that we're going to break all their rules up front ;) Regarding your second point, I think we simply must be prepared that this WG could have no outcome at all, if we can't get people agree on too many or some too important things. -- MarioSalzer?

If you folks end up needing a mailing list, I can set one up on SourceForge on the "interwiki" project. Or, better, I can add one of you (or all of you) as an admin on that project and you can administer the new mailing list yourself. S.F. lists use GNU Mailman software. Dunno if you prefer that or if you prefer freelists.org (Ecartis, I think). -- BayleShanks

Thank you, but Eeeyk - noticed your offer too late. Not that we must keep it, but I've fired up a list at http://freelists.org/list/wiki yesterday. (OTH I really prefer it, less ads, zero spam, nicer UI). The WG has already been rejected, because file formats aren't really an IETF issue. And btw, I'm tempted to create a page with an overlengthy name here - "WikiMarkupStandardWorkingGroup" or so, to move this discussion onto. -- MarioSalzer?

This is really exciting folks, good work! Best, MarkDilley

Exciting indeed. Make WikiMarkupStandardWorkingGroup and keep wiki more or less informed about how it's going. :) -- MattisManzel

Technical Issues: Since WikiMarkup? parses are mostly no parsers, just iterated regular expression replacements of specially ordered markup rules, it would be technically really hard to convince people changing their rules and engines. This would all be no problem if the engines would be real recursivly descendent parsers, of the intermediate format could be easily converted to the native markup. But this would slow then the engine a lot. And some ordering of rules are really tricky, such as ours to detect blocks for nested identation, and then go on with the normal inline rules. --PhpWiki:ReiniUrban

There'll always be more advanced WikiEngines, which support full nesting of all possible markup (lists in tables, list in indented blocks and such); but of course we should take care not to require too complicated things from implementors. Good hint. -- MarioSalzer?

Really a mailing list? I'd like to be able to follow the developement without getting more email. A wiki would be appropriate. This is important, how the thinking on it grows should have a publically accessible history. No new wikis for peanuts, sure. CoconutWiki?. -- MattisManzel

Using a mailing list for discussing wiki stuff sounds like using MS Word for writing Free Software documents. -- anon

Sure, it's somewhat poor not to do it in-Wiki, but the WikiMarkupStandard page here on MeatBall somewhat staled and it didn't become the central meeting place it should have been. Mailing lists are often simply the best way to discuss things in full detail. Btw, we're going to use OpenOffice? ;) to collect markup snippets. -- MarioSalzer?

Mattis, I felt our WikiMarkupStandard page wasn't known all too widely. I think separating the discussion from MeatBall makes it more interesting to others (else it looks like we'd favour UseMod syntax). Also the history of mailing lists is ok, sometimes better than for Wikis. But, don't worry - the final document will be edited in-wiki (wherever), and I try to keep this page updated. -- MarioSalzer?

I have had to stop using Email more and more lately, given the spam problems that now increasingly persistent. I would, however like to contribute, as best I can, so I would be interested in having an RSS feed that I could subscribe to. -- HansWobbe

In my opinion, a wiki and a mailing use can both be used by the same group to good effect. I say do both. It is desirable if all of the core participants both follow the wiki and also subscribe to the mailing list, but it's possible to do without (in my opinion), as long as some people are willing to act as "go-betweens", and post updates back and forth on the mailing list and the wiki.

To start off, having a page (or a cluster of pages) like this one on a large wiki like MeatballWiki makes sense, because this way you can build momentum and involve MeatballWiki's readers, many of whom would be moderately interested in this new effort, but who wouldn't bother to follow it to a foreign wiki.

However, after momentum is built, I would recommend moving the wiki side of the discussion to a lower-traffic wiki, but still posting frequent updates back to this page. This way interested parties can follow along without being overwhelmed with all of the unrelated Changes on MeatballWiki. I would say, at that future point, either start a new, small wiki for the standardization effort, or simply do it on InterWikiWiki?, which is pretty topically focused and low-traffic as is.

More urgently, I would encourage you to declare most of this page as PrimarilyPublicDomain ASAP so that there aren't copyright troubles later (e.g. in moving forums, in publishing the standard, etc).

(but, take my opinion with a grain of salt, because I probably won't a frequent participant in the group; so my opinion on its organization is not so important)

(this comment, like all of mine, is PPD)

-- BayleShanks

I think we could find a consensus that all standard related pages within meatball (we could create a category for that) are PD or FDL or whatever (but we have no decision process, so Sunir will have to decide). The problem will be - as always with standards - that objective aspects will not dominate the decision process. Engines that spread through OS will have a hard time to adapt to a new standard, so anyone will try to minimize the impacts of a new standard onto his product. If you count the voices, there will be no doubt that WikiPedia will come out as a de-facto standard. So its a constitutional problem (who decides), a technical problem (what are objective design goals) and a social problem (how to avoid a wiki world having a number of competing standards). It is weird that I'm the one who is least threated by a standards process, because all ProWiki software wikis run on servers that I maintain, so users can be informed and pages automatically converted on some future day. That's also why I'm not so much interested in the process.

BTW the standards process should not be seen as file format problem. We are talking about complex systems and need a language for that. So a wiki standard process should not only target "markups". Simple markup may be the first step, but others will follow. Language standards (title or caption, history or archive, versions or revisions, text or body, goals or mission, namespace?). But this is only a start. There are technical standards (what features make a wiki?) and social standards (what are the minimum constitutional elements of a wiki, what rights do users have). In the end, this process may decide what democracy means in a future (online?) world - in terms of transparency and participation. -- HelmutLeitner

In the long term, I agree; in a sense, I would like to eventually start working on "protocols for organizing social groups", or "operating systems for internet governance" (see also CommunityWiki:WikiProcess), but we can discuss those various standards in different working groups/forums -- for now a markup standard is enough for one working group! -- BayleShanks

I disagree with Helmut, we should keep focused on describing the text file format for now. This allows other poeple to use it in places, we couldn't imagine before. EMail is a likely candidate for adoption (again: Thunberbird already has it), so we shouldn't tie it to WikiWikiWeb applications only (which we effectively do, if we describe too many implementation details). What comes out could be accompanioned by other RFCs (e.g. WikiXmlDtd and WikiWikiTransportProtocol) though. -- MarioSalzer?

PrimarilyPublicDomain isn't necessarily the best idea for a standard. I wonder what the IETF rules are. Since we aren't likely to sue each other, we can fix it later. I'll declare the page PPD for now. -- SunirShah

Sounds good. -- BayleShanks

Yes it does. The IETF wants all the documents to assign all copyrights to them (at least for real-standards RFCs), text originally released as PD allows that. -- MarioSalzer?

I agree with most that has been said but I warn against taking this lightly as a technical issue. To solve it will require to arrive at a kind of global wiki community consensus. That means that the workgroup has to create constitutional elements (or worse, bypass them). -- HelmutLeitner

Yupp. Take it easy nevertheless. I mean the results count. Even a sinfony orchestra playing Mahler sounds better, when taking things easy. ;) -- MattisManzel

3. General Decisions

3.1. Decision Process

This is the hard part. I would suggest to that we tag decision with something like "Vote:" + plus a date when the vote is intented to start. This should be at least some days in the future. So everyone can add and edit different options and may be extent the start date. I would suggest that people vote by adding their name and their wiki engine if they are developers.

Does this discriminate users, too much?

I would not implement any automatism what happens if any point gets a majority.

-- FlorianFesti?, MoinMoin

3.2. What kind of Standard

There are several posibilities how a Wiki markup standard could look in the end - of cause mixtures are also possible.

3.2.1. Single Markup Standard

Define a set of formats and have one markup for each. Wikis are supposed to support this set of tags - either by supporting an additional format or by moving to the standard. This means that most wiki engines would either have to carry the burden of two parsers or have to write a converter (which might be not that trivial)

3.2.2. Describe what we have

Make several variants that describe what markup is used right now. Perhaps unify very similar markups. If you meet text/wiki, variant="usemod" you know what tags are in.

3.2.3. All in One

Sum up all used markups, remove the conflicts and "too weird" variant. Wikis are supposed to work with all markup within the same text. Wiki engines would have to extend their parsers to the standard markup and perhaps (re)move some few markups.

3.2.4. Senseful recommendation

List the markup, that was voted as being the "best", but also mention some of the more often used / alternatives in a final summary table. Overall: be flexible, this is NOT an all or nothing decision. There are points, where we must allow multiple markups, and others where we have a clear winner and don't need to mention alternatives.

3.3. What to Standardize

Only standardize a small feature set or standardize "as much as possible".

Small features set:

Full feature set:

3.4. Level of Detail

How exact should this standard be? Do we want to provide regular expressions? Do we want to discuss things like needed white space? Do we want to be the standardized markup tags to be exchangeable between wikis?

3.5. Design Goals

If we don't want to argue by personal likes and dislikes we need some goals we agree with. Also there are many goals that may be worthwhile some of them are exclusive and we have to choose an order of importance. (This list is still unordered, it is numbered so we can debate easier about it by saying "23541".)

  1. Readability of the source.
  2. Easy to break to avoid quoting problems.
  3. Hard to break to make it easy for beginners to get it right.
  4. Close to already used markups.
  5. Consistency for the markup set.
  6. Compatibility to advanced addon features like table attributes, start number in lists...

(Please add more.)

3.6. Markup Family

What markup familiy to standardize?

4. Design Decisions

4.1. SGML/XML tags

Some wiki engines do not support tags and do not want to suport tags. But there could be an tag base WikiMarkupStandard. Possible options are:

4.2. Line-based Markup

End of line terminates item. This limits the ammount of text such items can have. Line based markups cannot be nested! This may be desired.

Candidates: headings, list items, table rows.

Use a non-line-based variant? For tables perhaps?

4.3. Text Formats

Just switch format on and off or require TAGtextTAG?.

What about nesting?

4.4. Mark-up Guidelines

4.5. What to Avoid

Is there markup we want to avoid or we want to make difficult? Candidates are:

(Add more.)

5. Markup Elements

List of markup elements. To do: explain the nonobvious.

This a meant to be a comprehensive list. May be we will exclude some of them later because we don't have an nonconflicting markup for all. List is copied from WikiMarkupStandard, please add more if you are missing some.

Classification:

B
Basic functionality of a wiki. Wikis that support the standard must support these.
O
Optional functionality that is common among wiki implemetations. Part of standard but not required.
X
Excluded from the standard. (Perhaps excluded markup can be standardized as a HTML-like tag.)

Added some classifications as starting points. Please do not discuss in this list but add an questionmark and discuss below.

6. Universal Markup Rules

These are rules which are universal to virtually every Wiki (excluding those which use SGML/XML or TeX? instead or which don't implement the feature in question.)

Not much at the moment, but hopefully more will be added soon.

Discussion

IWML and the XML DTD was effectively rejected? I wouldn't say so, I for one am very enthusiastic about them (but then, I'm not writing any wiki page interchange software in the next few months)... although I agree they should not be defined in this RFC. -- BayleShanks

No, it is just off-topic here, we cannot discuss the two things on the same mailing list. That would only hinder the current work. It's not that it wasn't useful, but the WMS is more important currently. -- MarioSalzer?

We will ignore the hard problems of a interchange format right now but start to collect the tags while discussing the markup standard. So we should endup with a name for the tags, its attributes and a description of semantic (which we need anyway for describing the markup standard). We can even change the file format type to something else than XML later, but discussing the tags twice doesn't make sense IMHO.

BTW, this applies to most standard but especially here: there's a high chance that the standard as designed will end up being not what people want to use. I don't think we should prematurely bind "text/wiki" to a particular markup. Make an RFC, yes, "standardize" it, yes, make software that uses it, yes, but don't ever specify that "any document with MIME type text/wiki MUST .... (anything) ....", at least not until this standard is not only a standard on paper, but a de-facto standard.

Or, if binding to text/wiki is highly desired, be absolutely sure that the standard allows people to throw these rules out the window if they do "text/wiki; variant = ___" (or Murray proposal; or whatever).

-- BayleShanks

But, that's exactly what this all was about! The variant= parameter wouldn't make sense, if we didn't allow for markup variations and extensions. -- MarioSalzer?

In my opinion, you're going about this all wrong! Wiki markup variants seem to have some aspects of religion to them, and believers will fight back. The thing that ought to be canonized is the content model: ie, an XML DTD. This way, at most two translaters need be written: myWikiMarkup2xml and xml2MyWikiMarkup. This need not imply that a wiki implementation must keep it's content store in XML format, but a conforming wiki implementation must have those actions available. It forces conforming wikis to all implement the same set of markup features, but decouples the feature from the characters used to mark it up.

Once a DTD is in place, the next step is an XSLT stylesheet to convert canonical WikiMarkupLanguage? (WML) into (X)HTML. This would act as a reference implementation and help ensure that, no matter the idiomatic local markup used for a particular feature, the resulting HTML is the same.

It's also worth noting that, at least some, wikis have non-visible markup that are more akin to processor instructions than markup and may have an effect on page content. Accounting for these and getting agreement on what constitutes a standard set is where the cat herding is going to come into play... ;)

I think this approach has a better chance of success. It defuses any "my markup is better than yours" wars, plus it reduces the workload on implementors who want to conform. -- DavidLeBlanc?

I haven't been following any discussions on this subject for the past six months, so I don't know where IWML was ever "rejected" (and who has any authority anywhere to reject anything), but I will certainly support what David says here. If you simply mean that the IETF rejected the proposal, I could have told you that -- they said back with HTML 2.0 that it would be their last markup language. It's not what they do. But I should point out that the [XML Topic Maps (XTM) 1.0 Specification] was written up by a group of people that got together as an ad hoc organization for one year, at the end of which TopicMaps.Org no longer existed. Yet there are a fair number of companies developing products based on XTM, various projects using it, and it's now been incorporated into the ISO standard. There's no authority necessary here except success. If a group of people just start doing something well-designed, the rest of the community will eventually join in. This doesn't always happen (witness RSS), but it often does.

With wiki the ground rules are so much simpler, it's almost designed already -- I would suggest that it is. It's silly and pointless to try to capture the gamut of what people might like to see in a wiki interchange format, or to try to capture the gamut of markup expression out there. That's like trying to write a global dictionary. The low-hanging fruit, or the "80/20" point on this one is essentially what the vast majority of wiki can commonly express online, and that is almost completely by definition some variant of HTML/XHTML, simply by virtue of being online. If we assume that most wiki don't expect to be able to losslessly intercommunicate JavaScript or complex features, then any published "standard" for HTML or XHTML would do as an interchange syntax.

Now, if I'm correct in saying this, it's not a matter of "once a DTD is in place" as there is already at least several. We could simply adopt one of the existing HTML or XHTML DTDs from the W3C, or if they're all too fat, use the IWML DTD I developed. It's developed as a proper subset upon the modular XHTML DTD framework (which I wrote) so it's compatible with all other XHTML DTDs. Because the DTD is modular, it's possible to add or remove a module here or there, say, forms or tables or whatever. I think most everyone would agree that it should be some form of XML, which rules out HTML. But XHTML is easily processed by a number of relatively convenient and stable APIs. My own software applications frequently use XHTML as a data format, which has the advantage that those data files are web browseable. I can query, convert them into other forms, or make modifications either via the DOM, SAX, JDOM, etc. or via XSLT. If I'm less exacting, perl or python would do fine.

What I almost always find frustrating about committee work (and I've done enough of it, believe me) is that what would take one or two people a week of work can easily take a committee over a year. If there are people who need some kind of XML interchange format in order to convert content between wiki, stop talking about it and just do it. There is IWML, and if that's not what anyone wants, just use XHTML 1.0 Strict. Another six months will pass and there'll still be just discussion. I finally unsubscribed from the Standard Upper Ontology (SUO) mailing list after following and participating for several years, when I realized upon reading the archives that the status quo had been in place for years prior to me joining -- just talk, more talk. And in looking at the SUO archives now, several years later, they're still no closer to an operable first draft. Lots more talk.

That doesn't have to be the case here. Once content is some valid form of XML (and XHTML qualifies here), it's always, always transformable should the situation change. It's better to iterate towards a solution by starting even with the wrong one than to never start at all. What's that quote from Yoda? There is no try, only do. Or something like that... My only understanding of this is that nobody actually needs a WikiMarkupStandard, otherwise it would already be happening. -- MurrayAltheim

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: