Talk:Parsoid/Roadmap

Notes from Parsoid team meeting on 2013-01-09
Storing HTML DOM instead of Wikitext
 * Concerns
 * Templating
 * Recursive parameters to templates might be difficult to represent as DOM fragments - especially when the template is affecting an attribute
 * Wikitext template parameters are not necessarily properly nested (token stream)
 * What constraints, if any, do we want on template parameters?
 * What constarints, if any, do we want to enfornce on template and extension output?:Ex: well-nested DOM
 * Enforcing properly nested output of individual templates or combinations of templates is actually not that hard
 * Supporting templating capabilities on DOM that is equivalent in power to wikitext templates
 * What additional meta information needs to be added to the DOM to support the new functionality (fragment caching, parsing, etc.)
 * Possibly, don't support the new templating language (expressions, iteration etc) within articles, but reserve for a special namespace or content-type
 * Multiple template languages: Lua, wikitext are special cases of a general pattern
 * Possibly have some way for templates/Lua to specifically support visual editing
 * Lua modules can maybe export a %%__%%veinfo%%__%% method or similar to describe its parameters (using RDF schema similar to templates?)
 * Templates could probably have a subpage (e.g. /doc on enwiki templates, but for machines instead of humans)
 * We already set the RDFa namespace for the template to the template page, which could include an (RDFa-encoded?) schema
 * And a hook for rendering, see below
 * Non-compliant templates/Lua modules/tag extensions can easily be alienated (but that's not Parsoid's problem obviously)


 * Benefits
 * Faster than a parser
 * The cluster won't be overly affected by the change, as storage is organized amorphously


 * Things we need to do
 * Make a prototype that people can see in action, so we can convince them to take it seriously
 * Tag extensions
 * Maybe use an HTTP GET request to MW to get the result of any parser hooks (maybe use this for Lua, templates, etc. etc.)
 * Current Lua is hard to support outside of the PHP preprocessor because of parent frames etc
 * Can enable ESI (Edge-Site Includes) which we could use for fast-changing fragment from e.g. Wikidata
 * Methods to provide access to HTML-expanded article text
 * Warmed cache

Random thoughts If wikitext support is removed, wiktiext-based editing can be supported via an extension Way for a template to set its own "max-age"

ESI would be a benefit for logged-in users

What is the implementation path that lets us experiment with html storage while meeting VE launch goals for the summer?
 * side-by-side html storage for sure, but more details.

Etherpad etiquette: Name yo'self!

non-WMF wikis
"We will support simple HTML-only wikis with VisualEditor front-end without the need for a Parsoid installation. Besides other tweaks, this means that we will be providing a visual diff interface in place of the current wikitext-based diff."

Great news! Sharihareswara (WMF) (talk) 05:09, 25 January 2013 (UTC)

Research / prototype: HTML-only wiki support
It is excellent news that you are working to make it possible for smaller Mediawiki installations to use the VE. However, I fear that the path to combine this with "html-only" wikis is not welcome. For the foreseeable future smaller wikis will need many features beyond diff that are presently based on wikitext, especially for import/export, mass-replace, refreshing-operations, etc. Furthermore, independent of the size of the wiki-installation, most wikis have experienced editors which are likely to prefer continuing to tackle editing, and especially editing problems in wikitext.

I would therefore like to encourage you to focus resources on making it as simple as possible for small installations to install the full feature set, with wikitext and html working in parallel and parsoid combining the two. --Vigilius (talk) 23:49, 30 January 2013 (UTC)