Simetrical wrote:
I don't think it's realistic to expect total lack of change in the parser anyway: often it's a good idea to tweak parser output slightly to add new classes, style things a bit better, or whatever.
I think it helps to break things down conceptually into three categories: input format, storage format, and output format.
STORAGE format should be extremely well-defined and stable, hence XML.
There could be (and probably should be) a variety of INPUT formats: wikitext, WYSIWYG, etc., each of which is defined through conversion rules that turn them back and forth into the storage format.
The could also be a variety of OUTPUT formats. In addition to the current HTML, there could also be an audio output format, a "plain text" format, maybe a "summary" format (consisting of the lead paragraph and a table of contents for the rest), and probably some others I haven't thought of. Again, these would be defined through conversion rules.
I imagine there would be some third-party development of input and output formats for a variety of uses.
-------------------------------- | Sheldon Rampton | Research director, Center for Media & Democracy (www.prwatch.org) | Author of books including: | Friends In Deed: The Story of US-Nicaragua Sister Cities | Toxic Sludge Is Good For You | Mad Cow USA | Trust Us, We're Experts | Weapons of Mass Deception | Banana Republicans | The Best War Ever -------------------------------- | Subscribe to our free weekly list serve by visiting: | http://www.prwatch.org/cmd/subscribe_sotd.html | | Donate now to support independent, public interest reporting: | https://secure.groundspring.org/dn/index.php?id=1118 --------------------------------
On 3/7/07, Sheldon Rampton sheldon@prwatch.org wrote:
Simetrical wrote:
I don't think it's realistic to expect total lack of change in the parser anyway: often it's a good idea to tweak parser output slightly to add new classes, style things a bit better, or whatever.
I think it helps to break things down conceptually into three categories: input format, storage format, and output format.
STORAGE format should be extremely well-defined and stable, hence XML.
There could be (and probably should be) a variety of INPUT formats: wikitext, WYSIWYG, etc., each of which is defined through conversion rules that turn them back and forth into the storage format.
The could also be a variety of OUTPUT formats. In addition to the current HTML, there could also be an audio output format, a "plain text" format, maybe a "summary" format (consisting of the lead paragraph and a table of contents for the rest), and probably some others I haven't thought of. Again, these would be defined through conversion rules.
I imagine there would be some third-party development of input and output formats for a variety of uses.
XML is more of a data interchange than storage format. If you're storing data, and the software which is using it is the only source or destination, there is no clear reason why one would use XML, unless you're using it for data structure. But MW currently needs no structure; you're either storing metadata (in the db) or the article/page contents (text, with some output parsing, but just text; also in the DB, but only for convenience of access).
If the parser is going to stay the same, then there's no reason to change the storage format to something which requires an intermediate parser before the output parser.
If one wants to input different formats, then they can be parsed into the Wikitext test file via the input parser.
If one was going to write a whole new Wiki tool with Mediawiki's general performance from scratch, then it might make sense to reconsider whether a neutral, interchange oriented storage format like XML makes sense. But you'd really have to see what you're talking about doing interchange with and how, to see if it's worth it or just pointless overhead.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Sheldon Rampton Sent: 07 March 2007 18:23 To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] AJAX and .aspx as technologies for MediaWiki?
Simetrical wrote:
I don't think it's realistic to expect total lack of change in the parser anyway: often it's a good idea to tweak parser output slightly to add new classes,
style things
a bit better, or whatever.
I think it helps to break things down conceptually into three categories: input format, storage format, and output format.
STORAGE format should be extremely well-defined and stable, hence XML.
There could be (and probably should be) a variety of INPUT formats: wikitext, WYSIWYG, etc., each of which is defined through conversion rules that turn them back and forth into the storage format.
The could also be a variety of OUTPUT formats. In addition to the current HTML, there could also be an audio output format, a "plain text" format, maybe a "summary" format (consisting of the lead paragraph and a table of contents for the rest), and probably some others I haven't thought of. Again, these would be defined through conversion rules.
I imagine there would be some third-party development of input and output formats for a variety of uses.
MediaWiki is in constant development, so nothing is stable. And therefore any third parties are going to be playing catch up, almost constantly.
Jared
wikitech-l@lists.wikimedia.org