On 1/23/08, Tim Starling <tstarling(a)wikimedia.org> wrote: Hmm, ok. I'm having a bit of trouble picturing this XML format that includes "preprocessed" wikitext but doesn't have templates substituted? Do you mean that at this stage you've parsed the structure of template and parser functions calls, but haven't yet substituted in the result? I think I agree that such an early stage of processing is not the place to generate an exchange format. However, the XHTML level seems too late: instead of a neat "image" node, you'd end up with all the DIV tags used to actually display the thing in MediaWiki - as opposed to being an abstract representation. Anyway, if I have understood the situation, writing an export of an interchange format would just be a lot of work, with no special benefit for us, to solve a problem there is not currently any great demand for. I think. Steve

On 1/25/08, Thomas Dalton &lt;thomas.dalton(a)gmail.com&gt; wrote: Well, not as abstract as say the new WikiCreole interchange format: <xsd:complexType name="imageType"> <xsd:sequence> <xsd:element name="uri" type="xsd:string"/> <xsd:element name="alternative" type="simpletextType" minOccurs="0" maxOccurs="1"/> </xsd:sequence> </xsd:complexType> There is then an XSLT layer to convert from that to actual XHTML: <xsl:template match="image"> <xsl:text disable-output-escaping="yes">&lt;img src=&quot;</xsl:text> <xsl:value-of select="uri"/> <xsl:text disable-output-escaping="yes">&quot;/&gt;</xsl:text> </xsl:template> So it looks to me like there are the following layers in a conversion from wikitext to a rendered page: 1. Raw wikitext 2. Pre-processed wikitext before template transclusion 3. Pre-processed wikitext with template transclusion 4. Parsed wikitext into some abstract representation that understands 'bold' and 'image' but doesn't specify display 5. XHTML 6. Visual interpretation of the XHTML as performed by the browser You've suggested that the XML generated by MediaWiki at 2 is no good as an interchange format, and that 5 is suitable. I was (am?) just wondering about the benefits of splitting the XHTML-generating parser into steps 4 and 5, and making 4 generate an XML interchange format, possibly compatible with wikicreole's. which focuses on processing input, then a *code generator* (probably written in XSLT) that produces output. Obviously I'm only talking about doing this in a new parser, if/when that happens. The benefits would be too small to contemplate hacking that into hte current parser, I would think? Steve

On Jan 25, 2008 6:44 AM, Tim Starling &lt;tstarling(a)wikimedia.org&gt; wrote: Because for some purposes (e.g., a WYSIWYG editor), conversion both ways needs to be lossless, which it almost certainly won't be. You could do very verbose comments, but those immediately break when the user actually edits something (in the WYSIWYG case). If MediaWiki had been designed from the beginning to internally store almost everything as HTML, it would be at least conceivably doable to have a JavaScript HTML-to-wikitext converter that would be lossless, given appropriate annotation of the HTML (for templates, images, extensions, etc.). With wikitext, that's almost certainly impossible, so you have to just throw something together and hope it works well enough in most cases. WYSIWYG is really the main motivation I see behind constructing a well-defined format of any kind. It would be nice if we could interoperate a little better with third parties, but I haven't seen any compelling application that needs this, and couldn't just use the HTML with maybe some comments to indicate templates. The compelling utility of interoperability is not with third parties, but with clients -- our own users' web browsers. Unfortunately, this is probably not ever going to happen. Or at least not for a long, long time.

On Jan 25, 2008 7:55 PM, Tim Starling &lt;tstarling(a)wikimedia.org&gt; wrote: Do you think HTML two-way conversion is actually plausible, though? (I wasn't even considering WikiCreole.)

On Jan 26, 2008 8:03 PM, Tim Starling &lt;tstarling(a)wikimedia.org&gt; wrote: It might be easier if you could just not allow editing of things like templates (and other complicated things). I guess you could then use a bog-standard client-side HTML editor with only a bit of encoded metadata lurking about the place, and translate it server-side to wikitext. Not rendering templates as HTML in this mode -- e.g., substituting placeholders, or having the raw wikitext clear set off from the rest of the document somehow -- would undoubtedly be acceptable. In fact, isn't this basically what Wikiwyg does? It should be straightforward to design such an editor. It need only provide semantic markup, is all. There are some editors for various formats that do this, typically billed as WYSIWYM (although I admit to not having used any). A WYSIWYG editor that provides only the markup options offered by basic wikitext now couldn't possibly be less semantic than the current wikitext, could it?