[xwiki-dev] [ArchitectureV2] Model proposal

Wed May 30 11:07:18 CEST 2007

Hi everyone,

The issue of requirements seems very interesting to me with respect to this
discussion.  Clearly JCR and XWiki do not have the same requirements but
there is certainly a lot to be learned from a generic content repository
architecture for XWiki.  My first thought is that given the importance of
wiki level scripting in XWiki everything must be done to move towards an
easy to use, flexible and powerful system at that level.  On the other hand,
a first class citizen abstract JCR compatible content model in the core
sounds like it would also have many advantages including the capacity to
span different concrete repository implementations.   Actually the JCR model
proposal is basically a meta model for a domain specific XWiki model at it
seems we would need both to get the best of both worlds.

Now looking at this from the scripting side, it would be very cool at one
point to go even further and actually be able to benefit from a solid
extensible meta model in the core by mapping an XWiki application level data
model composed of Wiki level classes and objects and their relationships
into scripting.  For instance, let's say a project management application
and being able to easily navigate between projects, tasks, milestones,
resources and other application level concepts in scripting.  It seems to me
that this is the type of thing that could be enabled at one point by having
a solid meta model in place like the one suggested by Stéphane.

Luis

On 5/29/07, Ludovic Dubost <ludovic at xwiki.com> wrote:
>
>
>
> Hi,
>
> Concerning the XWiki model and the JCR model, this is a really
> interesting and important discussion..
> There are quite a few benefits to have our objects comply with the JCR
> model. I've thought a few times about and XWiki model on top of JCR, and
> this not only for storage.
> I don't think we should view right away JCR as "storage".. We can
> definitively view it as an API also..
>
> The main question we should ask ourselves is:
>
> 1/ Can we maintain the old XWiki api to have a layer of compatibility on
> top of an XWiki model being a superset of the JCR model.
> 2/ Can we support a different storage mecanism using the JCR model than
> the JCR storage API
> 3/ Can we extend the JCR model with an XWiki model
> 4/ Do we like the JCR model (is it a api that is nice to use)
> 5/ How would the XWiki scripting api (new version, not compatible) look
> like using the JCR model
>
> Concerning the mapping of XWiki<->JCR. I'm not sure that Farm is JCR
> engine..
> In the current usage of the Farm, we have different DBs for different
> wikis in a farm.. Are we sure we can get this behavior from
> engine/repository
>
> Farm <=> JCR engine
> Wiki <=> Repository
> Space <=> Node
>
> Ludovic
>
> Vincent Massol a écrit :
> > Hi everyone,
> >
> > On May 29, 2007, at 5:43 PM, Stéphane Laurière 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/WikiModelV2.zip
> >>
> >>
> >> [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 <vincent at massol.net> 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.
> >
> > [snip]
> >
> > That's an interesting idea. However for me the relationship with JCR
> > is not an advantage and certainly not a requirement. We want our model
> > classes to be independent on any storage mechanism. However from a
> > design perspective it's interesting to evaluate how the model classes
> > could look like if they were using a Node API similar in design to the
> > JCR (which I don't know so well but I guess it's similar to the DOM
> > API too).
> >
> > I can see some pros and cons:
> >
> > Pros:
> > - flexibility in that it's easy to add a new node type
> > - genericity in that it's a hierarchical structure (a graph) and it
> > would support nested nodes
> >
> > Cons:
> > - less strongly typed API in general a more generic API vs a more
> > business oriented API with the API I proposed. Compare
> > Space.getDocuments() to node.getElementsByType(NodeType.DOCUMENT). Of
> > course I guess we could add a SpaceNode class that implements the Node
> > interface and that method could then have a getDocuments() API which
> > internally would be implemented as
> > getElementsByType(NodeType.DOCUMENT). There's still the problem of
> > doing "if"s on the node type to cast to the correct specific node
> > class. Personally I've always found the DOM API to be a real pain
> > (which is probably why there are frameworks like JDOM, DOM4J, etc).
> > - There are business APIs to implement too (not just navigating) and
> > these APIs don't make much sense applied to a Node. They do make sense
> > applied to business objects.
> >
> > We need to discuss this more and I need to think more about this too
> > to evaluate the consequences.
> >
> > Thanks for this interesting discussion Stephane
> > -Vincent
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > --
> > You receive this message as a subscriber of the xwiki-dev at objectweb.orgmailing list.
> > To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> > For general help: mailto:sympa at objectweb.org?subject=help
> > ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
> >
>
>
> --
> Ludovic Dubost
> Blog: http://www.ludovic.org/blog/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> AIM: nvludo Yahoo: ludovic
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki-dev at objectweb.orgmailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>
>

-- 
Luis Arias
http://www.xwiki.com
+33 6 14 20 87 93
skype : kaaloo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xwiki.org/pipermail/devs/attachments/20070530/1a62721a/attachment.htm 