As seen on DiamondWiki, I'd like to implement a way to specify meta and semantic data with every page. But right now, I don't know how to call that then:

• $data["meta"]["meta"] - sounds silly? even if this is what we want
• $data["meta"]["semantic"] - ???

Such a meta array would collect data like:

   Category: *TechInfo
   Category: Documentation
   Author: milky

(As seen on google:DiamondWiki) Which would help the search function, and workaround the ugly and even harder to maintain PhpWiki:CategoryCategory links below every page.

But I'd also like to have some pseudo-contral data in this array then, like an idea on PhpWiki: suggested:

   prev: *LastPage
   next: *NextPageInThisThread
   up: *CurrentBookChapter
   down: *NextChapter
   index: FrontPage

Which would be used by a specialized plugin printing forward and backward buttons, or even by the wiki2html for building a single document book out of the Wiki (or something like *DocBook).

The point now is, that merging the latter control meta information directly into our database entry {meta} field (= $data["meta"]) would someday lead to conflicts with control informations (like the "rights" and "owner" settings for example) and would break some security stuff.

And so merging the "prev", "next" with the "Category:" and "Author:" meta data into one text meta data field would be the best solution IMHO. milky

Andy: How about adding a second table and new $data[] entry for it? The database layers would have to be reworked, but the search function could then be database optimized to use the search capabilities of teh database engine. If the second table seems excessive I still suggest we use a new $data[] entry rather than $data['meta']['meta']['category'].

milky: Uh, this is again the "making the database incompatible to earlier versions" idea. Adding more SQL tables means, that db_flat_files, db_dbm and db_phpwiki13 won't work further. And I don't think this would help here that much (for the searching), even if it is complicated to make a grouped view of pages by using the new meta data information if it is serialized then.

But, eventually we don't need the {meta}["meta"], if we just merged the entries from the latter into the existing {meta}. We just need to be able to distinguish between the new page description meta entries and all current control meta data. - But actually this isn't all that complicated, because we already have two distinct namespaces in meta:

• http headers, like {meta}["Content-Type"]
• page control infos, anything that starts with a lowercase letter

So I would say, to make our new page descripton meta data, distinguishable from the other stuff, we only needed to add a character:

• {meta}["category:"]
• {meta}["*category"]
• {meta}["+category"]
• {meta}["%category"]

The prefix notation is probably easier to use, and I'll hereby register the leading dot "." for storing of secret page control informations (for the auth/password_locks plugins entry).

Another problem I see is handling of multiple entries for one page meta description name. For example a page could be in multiple Categories:

   Category: Development
   Category: Documentation
   next: DevelopersPage

Should we allow users to specify the above two entries merged into one using a comma? "Category: Devel, Doc"? This would then disallow to use pages with a comma already part of the page name like [*and,or,xor]. Therefore I would also like to store the new page desc meta into an additive array:

   $data["meta"]["+category"][] = "Development";
   $data["meta"]["+category"][] = "Documentation";
   $data["meta"]["+next"][] = "DevelopersPage";

This polluted the database only slightly, but accessing of the entries would be eased, and for things like "prev" and "next" one could always only access the very first name as the ...[0] entry.