XmlWiki

What is xmlWiki?

Articles in xmlWiki work just like the normal MediaWiki articles except that they can have an associated "properties" article named xml:Article, the contents of which is xml. This properties article defines rendering transforms, permissions, publishing etc for its "parent" article. XML articles are represented as a DOM object at runtime, and the content will be validated against any referenced DTD or xml-schema. If any XSLT's are referenced, xmlWiki will attempt to apply them to the article. If the XSLT-output-method is "html" then it will be reduced to a string.

The names of posted form data, or query-string data can contain XPath queries to direct the information into the artiles' properties-DOM before rendering (but after permissions!)

How is it Installed?

It's three scripts (source below) which are in an "xmlwiki" directory in the main wiki folder. the hack is applied or removed by running the xmlwiki/index.php script. If xmlWiki is disabled then the security layer is also disabled, so the xmlwiki directory should be accessible only by admin.

How does it tie in with MediaWiki?

Two pseudo-namespaces have been added "xml" and "sys". These are both XML articles, and their contents affects the article they're associated with. Any sys:article is readable and writable only by users in the "admin" group.

• The sys:user-article holds security information: <groups>a,b,c</groups>
• The xml:article (properties) contains information pertaining to the content like transforms, publishing settings, data-sources and queries, and permissions.
• sys:user articles are of docType xmlwiki:system, and xml:articles are xmlwiki:properties.

More Specifically

XmlWiki consists of five hooks which attach into the MediaWiki environment through /wiki/index.php and /wiki/includes/parser.php, so those two files need to be writable by the admin script (/wiki/xmlwiki/index.php). Following is a breif description of each hook and a list of the processes executed in each.

INIT:

This hooks into index.php after the environment has been established, but before any article or input processing occurs. This hook is actually the initial retreival and execution of the xmlwiki.php article.

• Define system-globals
• Define user-globals
• Define article-globals
• Retreive sys:user and user-prefs
• Retreive article-properties and default-properties and merge
• Security (Process permissions for this article and deny access if not readable)

INPUT:

This hooks into index.php before input processing so it can direct any XPath inputs into the article-DOM and transform them into a standard input for xmlWiki. This also handles write-permissions.

• Security (If not writable, change action to "view")
• Apply any POSTed XPath-queries to article-properties
• If saving and content is XML, apply XML-validation and change action to "edit" if invalid

OUTPUT:

This replaces the output rendering in index.php. It handles read permissions and transforms the xwskin-generated DOM-output with default-skin.xslt.

• Activate the xwSkin and request wiki-output
• If article has just been saved, apply onChange transforms
• If editing a new sys:user or xml:article, fill text-input with default content
• Insert any pending messages into output
• Return final result to browser

PARSER:

This hooks into the parse-function in includes/Parser.php. If the article is XML, it is validated and domificated. If it includes XSLT references, or has a transform-list in its xml:article then those transforms are also applied here. The article will be back in string form again after this.

• Check if content being parsed is the article, and is readable
• Apply data-transforms (article is a string after these are done)
• Apply geshi syntax highlighting if appropriate (and not a request for raw content)

SKIN:

This is a new compulsory skin (skins/xwskin.php) which renders the page output as a DOM-object so xmlWiki can apply design transforms to it rather than PHP-based templates. If raw content is requested, then only the articles own transforms are applied, because skins and page-layout are part of the xmlWiki environment, not the article.

• Apply view-transforms

Required Articles:

Before installing xmlWiki, the following articles should be present on the target MediaWiki. Later the admin script will install these if not present.

• xmlwiki.php and xml:xmlwiki.php
• default-properties.xml
• document.php and xml:Document.php
• geshi.php and xml:Geshi.php
• export.php and xml:Export.php
• default-skin.php and xml:Default-skin.php
• default-skin.css
• default-skin.xslt

Other Required Scripts:

A number of other support files ae required which should all be in /wiki/xmlwiki/

• xmlWiki admin script (installs and uninstalls the hooks)
• xmlWiki skin-hook

Article Properties

<read>User|group,User|group,User|group...</read>

<write>User|group,User|group,User|group...</write>

Read and write elements contain a comma-separated list defining access permissions for the article. Note that users have upper-case and groups are lower-case. Assigning group membership for users is set by admin in the users' sys:User page.

transform-article   - NOTE the transform stacks are being replaced by the nodal model soon

Any number of elements may appear in the properties, each containing one transform name. The transforms are applied in the order they appear in the properties object. The data transforms are applied before any wiki-parsing occurs, so they can generate wiki-markup if they need to. The data transforms are intended to apply to queries, filters and data sources of the article content.

They are one-per tag because they are a stack - a transform is removed from the object when it is applied, and may push more transforms onto the stack during its application to the article.

If a transform is XSLT or PHP it is applied or executed, if it is XML-properties it is merged with the current properties-environment. Simple cascading inheritence can be constructed in this way.

Commonly used data-transforms will be for database-querying which makes the article content into the result of the query. This resultant list then gets parsed and converted to html, then is processed by any view transforms.

<view>transform-article</view>

This is a transform stack which works in exactly the same way as the data transforms, except that they're all applied after the wiki parser has applied its markup rules and converted the article to html. These are intended to be dedicated to content presentation such as layout, language and style. If the transform is a CSS it is output as a stylesheet link in the document head with any other stylesheets such as default-skin.css or default-skin.xslt.

<onChange>transform-list</onChange>

A list of XSLT|PHP|XML-properties|CSS to apply if the document undergoes change. One of these transforms which will be commonly used is the publish.php transform.

<publish username="..." password="...">destination URL</publish>

A transform can use its name as the root-element(s) of its data in the properties object. There can be any number of publish elements each specifying a remote destination for the article to be published to whenever it changes.

The publish elements are only checked if the publish(.php) transform is included in the onChange list.

Default Properties

• default-properties.xml was added 2005-07-22

This article is writable only by the dev group and is used as the initial state of the properties DOM for all articles. The articles associated properties (xml:article) then extends this initial state.

XPath queries

The names of posted form data, or query-string data can contain XPath queries to direct the information into the artiles' properties-DOM.

The syntax of these names is: xpath:query:[[@]new-node][+]=value

where new-node is the name of a new element (or attribute if @name used) to create in the query result nodes. If no node name is specified the value overwrites (or appends if "+" included) the current result-node contents.

XPath queries allow the rendered articles to include forms which can direct information and requests back into the articles' properties to direct further processing.