30 May
2007
30 May
'07
1:29 a.m.
On 5/29/07, Stéphane Laurière <slauriere(a)xwiki.com> wrote:
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.
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/…
[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:
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.
On 5/28/07, Vincent Massol
<vincent(a)massol.net> wrote:
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.
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
XPropertyMeta
What would XPropertyMeta stand for?
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
Sergiu
--
http://purl.org/net/sergiu
XPropertyDefintion XProperty
--
Stéphane Laurière
slauriere(a)xwiki.com
XWiki Research
http://www.xwiki.com
http://concerto.xwiki.com
http://nepomuk.semanticdesktop.org
- (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