Separating article and meta-content - Wikitech-l

1 Mar 2004

I believe we need to start thinking about ways to better separate content  
and metadata. Making them editable separately, and perhaps making either  
type of content filterable, gives us room for expansion in the meta realm  
without impacting editability for users who just want the plain text.

Current meta-tags:
* interlanguage links
* __NOTOC__
* __NOEDITSECTION__
* category links (experimental)

Possible future meta-tags:
* <editnote> - shown on top of the edit box during editing, e.g. "Please  
describe new events in the present tense"
* <sizelimit> - for auto-archiving or size warnings
* __NOCACHE__
* __NOTITLE__, __NOSUBTITLE__ for navigational pages, Main Page
* [[Edition=Print]] and other name=value tags
* .. anything else that would be useful, but clutter on the article page

I see two possibilities, one of which I call the hackish approach and the  
other the clean approach.

== The hackish approach ==

Add a new tag, called <meta>. Content within <meta>..</meta> is shown in
a  
separate window, like this:

<pre>
 _________________________________________
|                                         |
| The PURINA brand of dogfood is very     |
| tasty. Critics allege that it is made   |
| of harvested souls from children        |
| in the third world.                     |
|_________________________________________|
 _________________________________________
| [[de:Fnord]] [[simple:Wormwood]]        |
| __NOTOC__ [[Category:Dogfood]]          |
| <editnote>Do not edit after dark</editn |
|_________________________________________|
[ SAVE ] [ PREVIEW ]
</pre>

There would be an option to hide meta-information during editing, and one  
to use the old (single-window) behavior.

The meta-content would be part of the regular cur_text, it would be simply  
concatenated with it / split away from it on demand.

Advantages:
* Relatively easy to implement
* single diffs for edits that change meta content and article content

Disadvantages:
* regular editing can still cause edit conflicts with meta-editing
* no easy filtering of meta-editing from RC, diffs

== The clean approach ==

It would of course be cleaner to separate meta-content in the database. If  
we desire to do this, we should do it as part of the pending database  
redesign. In this case we would have a text blob and a meta blob which  
could be edited separately without conflicts. Any edit of a text or meta  
blob would result in an entry in the recent changes log.

The most problematic effect of this change would probably be on the page  
history. Again, the most logical approach would be to list a change to  
either meta or article-content in the history, but perhaps in separate  
color.

Disadavantage:
* requires table redesign, might affect quite a few pages
* more difficult but not impossible to maintain single window behavior
* complicates diffs, esp. summary diffs

Advantages:
* makes it easy to filter meta-edits from RC, history
* meta-edits cannot cause edit conflicts with regular ones
* storing and retrieving the different types of data is a lot easier and  
less error-prone

== Thoughts? ==

I think before we go any further into the meta area, we need to clean up  
the separation, otherwise we'll end up confusing newbies. I'd appreciate  
feedback on how to do this.

Regards,

Erik