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)