This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

(This is a placeholder until a Wiki Metadata API specification is posted. -- MurrayAltheim)

Quoting Janne Jalkanen <>: [...] [Hide Quoted Text] It needs a proper metadata API... I don't particularly want to introduce anything new that would break anyway soon.

However, there are quite a few people over on this list who *are* interested in proper metadata stuff. I'd recommend that you kick off a task force to write up a requirements list (this is the same way as auth got implemented: Andrew wrote a really good requirements list, and I gave him direct CVS access to write the code, too ;-)

Murray or someone else, if you're willing to lead this task force, that'd be great. Or, if someone wants to start to maintain 2.4. and make it a stable, I can lead the effort, too... ;-)

Hi Janne,

Certainly I'm willing to lead this if I'm not stepping on anyone's toes doing so. As I mentioned to you privately, I'll be adding a metadata functionality to my implementation regardless of whether it ends up back in the JSPWiki codebase, but I'm happy to share it as well.

My requirements are fairly straightforward:

  1. be able to store basic Dublin Core metadata of the type commonly stored in HTML/XHTML <meta> elements as per the DCMI specification ''Expressing Dublin Core in HTML/XHTML meta and link elements''. This includes both DC and qualified DC using standardized identifiers.
  2. The metadata schema should be independent of the WikiPageProvider, in that it should be easy to implement for providers that can "natively" store the metadata along with the page, but there is to be no requirement on how the binding or storage between the page and the metadata is handled on a per-provider basis (i.e., we leave the details up to the developer of each provider)
  3. While the basis of the metadata should be the DC schema (since that is the most common worldwide standard and is suitable for what a wiki page might need), the metadata provider should be extensible so that other schemas or appropriately-namespaced metadata properties can be stored using either simple name-value pairs, or within an XML element containing the metadata, with appropriate namespace labelling.

Any other requirements people have, please send them into the thread and I'll collect them together onto a wiki page.

I have a basic implementation that does #1 and #2, and my needs for #3 are not very high right now, so I'd likely not spend much time on it, though I'd be very happy to have input on it once I get going on writing this up.

As Janne knows, I've almost finished a new XNodeProvider, which is a WikiPageProvider implementation based on the XNode API I developed for my Ceryle project, basically an XML backend that has per-document metadata. I'll be writing up both the spec for XNode, publishing the javadoc API, and releasing an open source implementation within the next month, sooner if I can get help from someone on posting it to SourceForge.

Co-workers on the metadata API are most welcome.



A few key parameters:

I'm not really worried at this stage that much about implementation, or even API, but what is clearly needed is a design of the repository structure. Things like:

"All page content shall be stored as wiki:text -properties under the respective Node"

"A Node shall represent a wikipage or an attachment"

"The xxx:type property shall define the MIME-type of the object. Wikipages shall be stored as application/x-jspwiki".

"The path to a wikipage consists of WikiFarm name, then the direct path name. E.g. /MyFarm/MyPage. There shall always be one Farm, called "Main".

You know, that sort of stuff. That's what's critical at this stage...

--JanneJalkanen, 19-Jun-2007

Dublin Core Metadata Terms for JSPWiki#

This is based on the Dublin Core Metadata Initiative schema, probably the most popular metadata standard on the Web.

A start at breaking this down property by property:


The title of the wiki page.

example One Minute Wiki

There should probably be a provision for an ISO language code to permit multiple language expressions of the wiki page title.


fixed value application/x-wiki+jspwiki

In the the DCMI schema, the type property would be expressed as Format, identified by the URI When expressed in a syntax that permits it, one should add "IMT" (Internet Media Type) as the scheme using the DCMI Term

The IMT (or MIME) type for wikis has been a bit of a holy grail for a long time. I'd not recommend putting 'jspwiki' at the immediate token following the 'x-' as it's really a flavor. In reading over RFC 2046 I'm rather torn between text/ and application/ given wiki text is generally human-readable, but what tends to kick it over to the application/ side of things is the fact that text/ requires a CRLF as EOL delimiter, and we plainly don't enforce that (nor do I think that CRLF is a reasonable line delimiter in 2007, but that's neither here nor there).

So what I'd recommend for the IMT for JSPWiki would be application/x-wiki+jspwiki, where the content following the + sign is the syntax identifier. It's not great (I think it'd ideally be a URL since I'm sure IANA doesn't want to register wiki syntax names) but it's okay.

We might want a way to express the difference between a wiki page and an attachment; not sure where I'd do that.


The initial creation date of the wiki page.

example 2007-03-22T09:44:52


The date of the last modification of the wiki page (i.e., its most recent revision).

example 2007-05-14T12:31:02


The initial creator of the wiki page (its first revision).

example JanneJalkanen


The editor of the most recent revision of the wiki page.

example MurrayAltheim


The URI identifier of the page (its locator and canonical identifier).

In previous versions of DCMES it was possible to use qualifiers on DCMES elements, so that one could express a subtype. I used to use this to express revision numbers (using the identifier but I'm not sure with the current Terms how this is done appropriately. Will have to look into how to express revision numbers since it's clearly a requirement.


I'm editing this on my local wiki so I'll copy more over as done. More to come...

-- MurrayAltheim, 19 June 2007

A couple of comments: The title of the page is coupled to its Node name, so that's probably not needed. Also, JSR-170 already defines UUIDs (as "jcr:uuid"), so dc.identifier is not needed either (though it can be exposed also as dc.identifier, if necessary). There are some other things that JSR-170 already provides, such as the "jcr:created" property.

Also, a small technicality, JSR-170 uses colons instead of periods, so it's "dc:contributor", "dc:created".

--JanneJalkanen, 19-Jun-2007

Also, JSR-170 defines a versioning API (using nt:versionHistory and nt:version types), so you don't have to worry about expressing version numbers; those come free with the API. They are also available through /jcr:system/jcr:versionHistory, so they already have a place in the Node tree.

--JanneJalkanen, 19-Jun-2007

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 19-Jun-2007 14:19 by JanneJalkanen.