[dokuwiki] Re: DokuWiki metadata handling
- From: Chris Smith <chris@xxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Mon, 10 Apr 2006 12:27:45 +0100
Hi Esther,
First off, I didn't mean anything by shipping my patch without a
separate file for meta data or additional header information. Just that
the code was already written and working + the fix for PType worked out
quite straightforwardly, so I just wanted to get the code shipped off
before it got stale.
I don't know anything about meta data standards. I have taken a brief
look at the two sites you mentioned. Can you perhaps provide a little
background judgement as to why you mention those two in particular.
e.g. Are there others, are those two organisations and the work they do
widely recognised and supported (at least in comparison with any others,
if there are any).
I like the idea of separation of meta data, from a technical stand point
the question could then become how Dokuwiki deals with that data.
Dokuwiki has a quite sophisticated parsing and caching engine.
Perhaps, and this is just *thinking out loud to provoke discussion*, it
would make sense to use the generalised case of that...
- we have an xhtml renderer for the main display of wiki pages.
- add an RSS renderer for handling RSS feeds
- add a meta renderer for production of meta data
- ...
The "chassis" for Dokuwiki's parser provides all the necessary cache
management. Writing an RSS renderer or meta renderer should (in theory)
provide cacheable output. Extending the paradigm, an RSS template could
return the n most recently modified pages.
Efficiency is obviously a consideration and if in the case of meta data
it isn't expected to be dependent on other sources, maybe it is ok for
meta data to be produced at instruction generation and hived off
separately. If so, what format should it be stored in? (It was that
question that started the train of thought which lead to the idea of a
meta data renderer).
- XML?
- serialised PHP?
- handled like ACL, allowing some wiki's to store it in a database for
more sophisticated indexing and/or combination with the same information
from other sources.
Should the renderer perhaps return:
- the rendered document (not including the toc or section edit details)
- the toc
- the section offsets and lengths
- metadata (maybe including the toc and the section offsets).
allowing the template to decide how to organise the page, especially toc
placement and section edit buttons
Lastly, if you're still reading :-), are there now two types of document
meta data.
- meta data used by dokuwiki, e.g. first heading (title), TOC, no cache,
no toc,
- meta data for external use, e.g. title (first heading), creator,
keywords, TOC
Does this argue for keeping a serialised version within the instruction
list and an accessible version (location and format accessible)
although not necessarily produced within the renderer....
Cheers,
Chris
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
