On 5/29/07, Stéphane Laurière <[email protected]> wrote:
Hi Vincent, Sergiu and all,
Some remarks below after having discussed today with Mikhail Kotelnikov (in CC, author of WikiModel, co-founder of Cognium Systems, a partner of Nepomuk that XWiki company is part of [3]).
[1] http://nepomuk.semanticdesktop.org/xwiki/bin/view/Components/WikiModel * WikiModel v2 contains an alpha version of a JavaCC grammar for the XWiki syntax. WikiModelv2 is common event model working currently with several wiki syntaxes: creole, gwiki, jspwiki, mediawiki, xwiki.
[2] WikiModel v2 source code download: http://nepomuk.semanticdesktop.org/xwiki/bin/download/Components/WikiModel/W...
[3] http://nepomuk.semanticdesktop.org
[4] http://www.cogniumsystems.com
The topic is not easy, we are aware several strategies are possible, here's a contribution :-)
Sergiu Dumitriu wrote:
On 5/28/07, Vincent Massol <[email protected]> wrote:
Hi,
Starting from today I'm going to spend some time every week on the V2 Architecture/Redesign. Today I'd like to start at the heart of the topic with the domain model. Here's my proposal:
* Model classes are classes representing the XWiki model. The main classes are: - Farm - Wiki - Space - Document - XObject - XClass Attachment
Couldn't we try to merge the Document, XObject and Attachment classes into a single class, along the lines of the JCR API where there is mainly a Node class that can have various types and various properties? An Attachment would be represented by a Node with a property containing a binary stream and possibly other properties such as the text description, the title etc. The advantage of this approach is to offer a simplified and more flexible model.
We can make a unified API for all these classes, and (as I said in my previous email) we already have something similar with BaseElement/BaseCollection. But I don't agree that this is where we should stop. Having specific classes to ease the usage is a must. Like Vincent said, why call node.getElementsByType(NodeType.DOCUMENT) when we know we want the documents in a space? This is why DOM didn't stop at Node, and it provides Attribute and Element interfaces, and even specific interfaces for the elements in HTML.
XPropertyMeta
What would XPropertyMeta stand for?
XPropertyMeta is the definition of XPropertyDefinition; a Meta lists the various settings for the different types of properties, thus defining what is a StringProperty, what is a NumberProperty, etc.
With Mikhail we tried to produce a wiki model that can be easily mapped to the JCR model, and we came up with the following core elements:
Why the JCR model? Does it provide any advantages that cannot be easily obtained with a different model? We should keep the model independent from the actual storage, because there are lots of storage models: relational, JCR, XML, RDF, db4o are the ones that get in my mind right now.
- Node (Document, XObject, Attachment would then be represented using Node instances) - NodeType (JCR terminology, equivalent to XClass)
- ID: our proposal would be to create a top level class for IDs so that (i) can have several URIs for the same ID, (2) all manipulations with IDs (renaming: giving a new URI for an ID) are distinct from Node manipulation, (iii) this will allow the implementation of a service dealing only with IDs and URIs separately from the Node implementation.
This is something I like. We should make ID-s independent from the name, as at the moment ID-s are strongly related to the name of the document, classname and number of the object. And this makes renames very hard, and aliases almost impossible.
- Session: similar to the XWikiContext and to the JCR Session class: it's the user's context, giving access to all repository services adapted to that context.
Is a session part of the *data* model?
In addition to these core elements, we should add to the model a Version class, but its scope remains to be discussed.
Just to see where we are on the map, we also drew the comparison below between the XWiki2 and JCR models: Farm <=> JCR engine Wiki <=> Repository Space <=> Node Document <=> Node Attachment <=> Node XClass <=> NodeType XPropertyDefinition <=> PropertyDefinition XProperty <=> Property XObject <=> Node
From the discussion we had, it appears that at least Cognium Systems would be interested in designing core wiki libraries that could be then used by their collaborative engine in addition to being used by XWiki. Obviously, other companies and researchers are likely to take part in the design of such libraries, given the importance of wikis. We believe that such libraries would have more impact if they are maintained by a wide community of companies and researchers, avoiding the situation where a given community fears to use some library because it has too tight links with a single company. This has to be assessed, though. What do you think?
I agree.
Within Nepomuk, we're currently designing such core wiki libraries. We will upload a Node API proposal this week, and we plan to implement it on top of Jackrabbit by mid-june. The more we can share efforts toward a sound and flexible implementation of the core services, the better, but obviously the XWiki2 strategy regarding the Nepomuk effort remains to be investigated and discussed.
Stéphane and Mikhail
XPropertyDefintion XProperty
- (probably lots of others) * As you can see I'd like to introduce the Space and Farm objects * We create a model/ build module in trunks-devs/xwiki/model for storing model classes * Model classes cannot access other classes outside of the model/ module. They are meant to be used by components to provide services but they shouldn't provide services themselves. They can methods to manipulate their fields and they can call each other but they cannot call outside of their model. * We use the org.xwiki.model package for storing Model classes * These model classes are all user public (API)
WDYT?
Agree
Barring any negative feedback I'll start implementing this today and in the coming days. One question that remains unanswered in my mind is how do we integrate back these model classes into the V1 architecture. I think we should be able to retrofit the existing classes to use these classes by composition. For example the Document object could have 2 fields: one org.xwiki.model.Document and one org.xwiki.model.Space. The XWiki object could have 2 fields: Wiki and Farm, etc. I'm not sure how this would work out though. Any idea is welcome.
Thanks -Vincent
Agree for XWiki, but I don't know why should we have a Space object in the old Document. Are there any Space methods in the current code?
You have my support. As much as my time allows, I'll help you on this.
Sergiu
-- Stéphane Laurière [email protected]
XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org
Sergiu -- http://purl.org/net/sergiu