Hi everyone, On May 29, 2007, at 5:43 PM, Stéphane Laurière wrote: [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

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(a)xwiki.com> wrote: -- Luis Arias http://www.xwiki.com +33 6 14 20 87 93 skype : kaaloo

On 5/29/07, Stéphane Laurière <slauriere(a)xwiki.com> 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. 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. 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. 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. Is a session part of the *data* model? I agree. Sergiu -- http://purl.org/net/sergiu

On May 30, 2007, at 12:59 AM, Sergiu Dumitriu wrote: [snip] The model should only contain data AND behaviors associated with this data. For example I'm pretty confident we want to have Space.getDocuments() for example in the model. Well this is the same as with the other option I believe as for example we would retrieve documents only when Space.getDocuments() get called the first time. Or do you mean something else? There's a dependency but it's a runtime dependency rather than a source time dependency. Yes, this requires some magic (byte code enhancement) if you want to make it transparent. Otherwise you need an API to load data and then only you're allowed to use the domain objects, which isn't nice. Yes we could. I know someone who's using it. I'll check with him. [snip] Thanks -Vincent

On May 30, 2007, at 11:54 AM, Sergiu Dumitriu wrote: [snip] Ok I agree but this can be done with either solutions. So I think we agree we want to have the Space.getDocuments() methods in the model classes and calling them will return database data (either when they are called or when the relationship is navigated). One drawback is that you need to tell somewhere where you want the interceptor to plug into. This can be done with a configuration file (I don't know how jpox does it) or it can be done using some annotation. In that case we come back to a source dependency but it has the advantage of being more maintainable (otherwise you need to ensure you config file and your class/methode names are always in sync). I meant model classes. [snip] Thanks -Vincent

On May 31, 2007, at 7:17 PM, Catalin Hritcu wrote: In that case they shouldn't be named XClass and XObject because this doesn't mean much. In no time we'll start calling XWiki developers X- Men... ;-) If we want to say "XWiki Class/Object" they should be named XWikiClass and XWikiObject. Same for Document, Space, Farm, etc because for example Document can be confused with DOM Document class, and we can probably find other libraries using Space, Farm, etc. Personally Class/Object doesn't bother me as it's in a separate namespace. Yes, that's a good idea. If we wanted to go that way, we could also call them something more business oriented like Definition (for Class) and DocumentMetadata (for Object). But I'm not 100% convinced yet we need to rename them. We can think about it. For now I think the most important decision is deciding what we do with Stephane's proposition of a JCR-like model. Thanks -Vincent

One more question. Do the model classes perform access rights checks? Or we assume that once they get past the API everything is OK? I'd say that all the rights checks should be performed outside the model; perhaps the API, as it is now. Btw, do we keep the "API" name for the scriptable model wrapper? On 6/4/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote: -- http://purl.org/net/sergiu

Hi Vincent, hi all, I tried to explain below which advantages I see in reusing JCR concepts as much as possible. Vincent Massol wrote: I agree we need in any case an expressive model that will capture the specific features of XWiki. However, since a significant part of XWiki features are already quite well expressed by the JCR API, we could take into account the well thought and well accepted JCR content manipulation concepts and APIs such as Node, NodeDefinition, NodeType, Property, PropertyDefinition, PropertyType, Workspace, Session, for adopting the following methodology: we could consider the current version of the JCR as a set of services to be supplemented with services that we're missing for building XWiki features, introducing specific concepts only when necessary. In that sense, I agree with Luis for saying that the JCR is a possible "metamodel" for our specific XWiki model. As Ludovic also pointed out earlier in this thread, we should not reduce the JCR to a storage API, since it is is a general API for representing operations on content, and is, as such, an API that models well part of our application behaviour. Note about Session: Session is not part of the data model indeed, but I think it's a handy class to be present at the model level, avoiding to pass the context to each method of the data model classes, as opposed to the current XWiki API. However, the JCR has drawbacks as well, and it is obviously missing important features needed for XWiki: - the JCR is too monolithic: all the services live in the same API, and new services cannot easily be added. Moreover, the API provides several identical functionalities from different places (redundant API example: a node can be moved from different classes: Session and Workspace). - the JCR is lacking a service for advanced management of properties: for instance, it's not possible with the JCR API to get all the back-references to a Node. - the JCR is obviously missing other services that we need for XWiki. Following a discussion with Mikhail, my proposal would be the following: Step 1: we split the JCR into the following services(to be possibly submitted as a JCR evolution proposal later on): - StorageService for atomic types including binaries - ContentMonitoringService - LockService - IndexingService - RepositoryAccessControlService - QueryService - XMLExportService - VersioningService - TransactionService - TypedPropertyService - DirectReferenceService - [...] probably others Step 2: implement those services using an existing JCR implementation, and also possibly using our own implementation, reusing the XWikiHibernateStore and the surrounding classes. Step 3: supplement these content services with the property management services we're missing for dealing with our XClass functionalities, but not introducing any specific XWiki concept at this stage. The advantage of having those services as extensions to the JCR instead of having them at the XWiki level is that the services would remain as generic as possible while providing easy interoperability with the JCR. Complementing the JCR with services providing advanced management of node properties is a topic that is currently of high interest to several communities. Participating in that effort may lead to a sound and standard API, implemented by several vendors, XWiki among others, and may make our community a strategic one among the emerging semantic web content repository initiatives. The needs for these supplementary services are well captured by the idea of a "Semantic Web Content Repository" in the slides below by Max Völkel [1],[2] and are mentioned in a recent email to the jackrabbit-dev list [3]. [1] http://swecr.googlecode.com/files/2007-03-12-SWECR-2.pdf [2] SWECR project: http://code.google.com/p/swecr/ [3] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg05524.html The services we're speaking about are typically the following: - ReferenceService (for manipulating object properties) - SparqlService (if we go for RDF for representing our classes and instances) - IdentityService (ID/URI mapping) - InferenceService They should in particular cover the use cases described by Sergiu in a previous post, which are of great relevance indeed [4]. Cognium Systems has expressed interest for co-developing such services with us, in an Apache License-like. [4] http://www.nabble.com/Re%3A--ArchitectureV2--Model-proposal-p10865097.html). Step 4: specify the specific XWiki services for dealing with structured and unstructured data as complementary services to the SWECR, and design an expressive model describing XWiki specific artifacts on top of the SWECR. Step 5: implement these services on top of an SWCR implementation Step 6: design and implement the other XWiki services (i.e. all those that do not directly relate to content manipulation). As a summary, here are two schematic stacks of models and services for comparing the two approaches we're discussing, as I understand them. Approach 1 stack ================ XWiki services --------------------------- XWiki type model: XClass, XProperty --------------------------- XWiki document model: Document, Space, Attachment, Wiki, Farm --------------------------- XWiki persistence service: Data Access Objects --------------------------- JCR impl.|Relational impl.|... Advantages: - we can quite easily implement several storages (JCR, relational storage) using Data Access Objects - the model is quite close to the existing one - we don't modify the JCR Cons: - the management of types and properties is not generic - people used to the JCR concepts have a complete new model to learn, without clear correspondance between XWiki concepts and JCR concepts - we have no obvious reason to participate in content management standardization efforts Approach 2 stack ================ XWiki services -------------------------- XWiki document model --------------------------- SWCR services: - Type/Property services - JCR services splitted into serveral ones ---------------------------- JCR document model, JCR type model --------------------------- JCR impl.|Relational storage impl|... Pros: - genericity of the property/types services - we embrace the JCR movement, and take part in its evolution - we take part in the emerging area of semantic web content repositories and the design of standard Semantic Web APIs complementing the JCR Cons: - larger effort - probably harder to implement a compatibility layer with XWiki 1.0 API - bigger performance risks Stéphane -- Stéphane Laurière slauriere(a)xwiki.com XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org