[Pmwiki-users] Re: Categories instead of hierarchies?

Patrick R. Michaud pmichaud
Thu Oct 28 23:33:06 CDT 2004


On Fri, Oct 29, 2004 at 10:19:02AM +0530, mistyfire wrote:
> Hello,
> As the complexity and size of wiki grows a "multi-category page" seems a lot 
> more logical than hierarchies. 
> I have recently joined the mailing list and was wondering if saving the native 
> wiki pages in XML format would be a good idea. 
> [...]

Interesting suggestion.  PmWiki 2 does allow changing the page storage
mechanism being used, so developing a "save page in XML format" item
would not be a big issue.

What is a non-trivial issue is maintaining the integrity of the
many cross-referencing links that this proposal introduces.  
For example, you propose having every wikipage contain a set of 
<category> elements for each category the page belongs to, and then
each category page (or a single common category page) has a set of <wikipage> 
elements for each page in each category.  Maintaining the referential 
integrity of these elements is certainly doable, but not trivial--adding 
or removing a page from one or more categories requires correctly rewriting 
the category page(s).  Also, many PmWiki administrators take advantage
of filesystem operations (copy, rename, delete) to perform various
page maintenance tasks--indeed, the ability to do this is one of the 
reasons PmWiki uses a flat file scheme--but these operations would no 
longer be available to administrators because they would result in
internally inconsistent pages unless there's some way of rebuilding
the associated indexes (more code overhead).

Thus, moving to XML really doesn't make the process of maintaining 
category relationships any easier--the same operations still have to 
be performed by the PmWiki code (i.e., determining the applicable 
categories and links from the markup, storing them as XML elements,
maintaining internal reference consistency among files).  But yes, 
XML could potentially improve the ability to search and query for pages 
matching certain criteria.  Of course, this assumes that PHP already
has the built-in tools to do XML-based search/queries for us (my initial 
reading of the documentation is that it doesn't, but I could be wrong
there).

Beyond that, I'd be somewhat concerned about memory overheads associated
with processing pages in XML -- many PHP installations run in a 8 megabyte
sandbox, and it's possible that XML-storage related overheads could
cause certain pages or situations to bump up against that limit.

Given PHP's minimal support for XML operations (e.g., search/query), I
don't see that XML-based storage gains a whole lot over PmWiki's
present storage mechanism at this time, except for possibly being able 
to apply XSLT transformations in certain situations.  And XML/XSLT is 
probably *way* outside of the technical capabilities of the audiences 
that PmWiki targets.

Thanks for the excellent suggestion, however -- I'll keep it in mind
and keep watch to see how support for XML/XSLT improves in PHP over time.
There's nothing that prevents us from adopting this approach in the future.

Pm



More information about the pmwiki-users mailing list