> You don't really need that though. The system identifier for the page > should include its full path. In my systems I use a collection/document
Actually, I disagree. This is problematic, if you move the page around. Therefore, it's better to use a synthetic property like jcr:uuid, which does not necessarily bear any relation to the path of the object. > In my system the page revisions are stored within the document record. It is useful to look at Mediawiki's storage model; they have a separate table for archived versions for optimization purposes. This suggests it might make sense to keep the version history outside of the actual Node. (Which is, incidentally what jcr does as well - the version history is exposed as /jcr:system/jcr:versionHistory/<node>) > a new field (within my own application profile) for 'system id' and > use DC.identifier for things like ISBNs, since my metadata records can > sometimes refer to a physical or digital resource that isn't stored > directly in the system. That's probably not an issue here either. I think that this suggests that we should keep our own identifier system and leave dc:identifier for user use. > I must admit I'm a bit concerned that the 3.0 design might lock out a > large number of existing backend implementations (including my own) with > a requirement to use the JSR-170 backend, since currently there are > variety of options, and we might assume we don't even know about the > custom ones that people have created. I'm working on a major project > that *might* migrate to JackRabbit but might not. If not, I'll still > need a way to use 3.0 with our systems. The XNodeProvider (Berkeley JE > based) is currently our way forward and I'm not in a position to scrap > that. So if there's plans to provide a non-JSR-170 backend -- in other > words we'll still have a WikiProvider API -- I'd like to know more about > those plans. Well, yes, there is, and I've told you about it already ;-) /Janne
