From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1NyVZs-0001iG-DO for garchives@archives.gentoo.org; Sun, 04 Apr 2010 19:33:48 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BE727E0933; Sun, 4 Apr 2010 19:33:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B560EE08C1 for ; Sun, 4 Apr 2010 19:33:29 +0000 (UTC) Received: from angelstorm (cpe-76-93-187-113.san.res.rr.com [76.93.187.113]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 4275E1B4040 for ; Sun, 4 Apr 2010 19:33:29 +0000 (UTC) Date: Sun, 4 Apr 2010 12:33:23 -0700 From: Joshua Saddler To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki Message-ID: <20100404123323.1689e9d4@angelstorm> In-Reply-To: References: <20100403163010.1897d663@mail.a3li.li> <4BB7D11F.7060207@gentoo.org> <20100404003152.4b2012da@angelstorm> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/0ukDvZgkLAlkcSwIpxb6NLi"; protocol="application/pgp-signature" X-Archives-Salt: 9cbd6b11-735c-47d5-bb49-32a331adbf9b X-Archives-Hash: 5996c4e731e5f36a226c7b12b960b6b0 --Sig_/0ukDvZgkLAlkcSwIpxb6NLi Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 4 Apr 2010 17:23:54 +0200 Ben de Groot wrote: > As has been pointed out, your table example was unfair, as they don't > do the same thing. I would frown on such inline styling (that's what > stylesheets are for), and there are a number of ways you can markup > tables in wikis. One is to allow HTML tags, so it would be very much > like GuideXML. Another one, which I prefer personally, is to use > reStructuredText, which is even clearer than HTML markup. Having to write a custom stylesheet just to get one wiki page to do what yo= u want is pretty dumb. How is it unfair? Because tables really are so much simpler to write in Gui= deXML? Here's a more complicated table: http://www.gentoo.org/doc/en/xml-guide.xml#doc_chap2_sect10 source: http://www.gentoo.org/doc/en/xml-guide.xml?passthru=3D1 > > By moving to a wiki, you'll lose a huge percentage of what GuideXML can= do, >=20 > I don't see that at all. Is there any essential feature of GuideXML > that is missing in MediaWiki? (Let's take that wiki implementation as > the most likely one we will adopt.) I haven't seen anything yet that > is impossible or very difficult to do. Do you really think that > GuideXML is so special and advanced that nobody else had the same > needs and that major wiki engines do not provide in those needs? Mediawiki mostly involves memorizing how many quote or tick marks you use. = This markup is *completely nonsemantic*. In GuideXML, you know EXACTLY what= each tag means. It's semantic.
    starts an unordered list.
      starts = an ordered list.
    1. is a list item. for bold text. for emphasized= text, similar to XHTML's tag. to start a table. Mediawiki requires you to memorize numbers of marks to achieve the same eff= ect: two ' ' for italic text, three ' ' ' for bold, five ' ' ' ' ' for bol= d AND italic. Now take a look at the section on Mediawiki lists: whitespace becomes part = of your formatting. Lame. At least with GuideXML, you can use whatever whit= espace or linebreaks you want to keep code human-readable, and know that it= won't affect the rendered version. Oh, *and* you have to prefix Mediawiki list items with ; and : , which is c= ompletely nonsensical and arbitrary. The character doesn't explain what it'= s for, unlike semantic XML tags. Take a good look at the Mediawiki "mixture of lists" sample: (I'd provide a direct link, but there's no built-in way to snap to it) http://www.mediawiki.org/wiki/Help:Formatting That is just plain ugly. The eye has a hard time unjumbling the ##s and ;:*= crammed together. Also, note another flaw of Mediawiki: At any time, you can throw in HTML and CSS to do stuff, because apparently = Mediawiki isn't flexible enough on its own to generate your desired renderi= ng. Having to mix HTML with a totally different wiki syntax is stupid. Havi= ng to learn CSS *on top* of learning wiki syntax (and HTML) just to write a= document is retarded. You've tried to make the case that learning GuideXML is too hard, but in or= der to use Mediawiki you'd need to learn at least 3 languages. In my earlier email, I shared a code sample of GuideXML tabls. Mediawiki's = idea of tables? {| to start. |+ for a caption. |- for a row. ! for headers, and | for data.= Use more || symbols for more rows. Seriously, what part of this is easily understood to be table markup? *And* you can mash in XHTML attributes to style the text. Big no-no. Leave = the styling to a separate stylesheet, and let the code just be code. Yeah, since Mediawiki tables can accept straight-up CSS (another skill you = had all better learn if you're going to write valid code, apparently), you = *can* do a bit more color formatting than with our existing XSL rules for G= uideXML. I'll grant you that. But that's at the price of standardization: since arbitrary tags and markup= is allowed, there's nothing to keep consistency between documents, or even= within the same document. GuideXML at least has a clean, consistent visual= representation. Once you start allowing arbitrary markup, there'll be a mi= llion and one ways of representing the same thing, and that's not good for = someone trying to wade through documents. There *should* be a standard way = of representing information. > And if you really wanted to, you could easily write an extension to > parse GuideXML, so it could be used as wiki markup. So again, the > markup is not really an argument against using a wiki instead of our > current GuideXML+gorg setup. Except I haven't seen Mediawiki offer anything like our textual color palet= te or other code syntax and block-level formatting flexibility. > 2. It is a non-transferable skill. You can't use it anywhere else. > And unless you are a regular GuideXML writer, you will have to > look up its particular usage almost every time you do use it. It's just XML. That's all. If you can write HTML, then you can write XML. X= ML is *easier*. It's got far fewer tags, for starters. That means much, muc= h less to learn. Oh, and guess what? You ebuild writers are already using XML every single t= ime you make changes to ebuilds: metadata.xml, etc. Most of us have used GuideXML at some point or another in our /proj/ webpag= es and devspaces, if not in /doc/en/. Guess what? That's the same XML, and = there's much, much more content constantly written for /proj/ and dev.g.o t= han for /doc/. So don't try to tell me that people don't have at least pass= ing familiarity with it. --Sig_/0ukDvZgkLAlkcSwIpxb6NLi Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAku46YYACgkQxPWMzpKk6kNn1ACeKS1orX3qotqIFMPmknRxPhle /pIAn39J9aYseByjW5ExKbr+JzZmrp56 =ifqB -----END PGP SIGNATURE----- --Sig_/0ukDvZgkLAlkcSwIpxb6NLi--