[Ricardo Rodriguez] Your EPEC Network ICT Team wrote: > Hi, Sergiu, thanks for the answer. > > Sergiu Dumitriu wrote: >> Well, a pretty simple solution is to use a Draft space, where guests >> don't have view rights and all the registered users have edit rights, >> and here people collaborate and create documents. When they consider >> that a document is ready for the public, they let the admins know about >> this, and one of the admins moves the document to its final destination, >> where only admins can write. >> > I agree, this is straightforward. >> This involves only a bit of access rights tweaking and the Rename menu >> entry, without any complex tools or processes, but it assumes that >> people are not evil and will respect the rules, which is usually true >> inside a company. >> > But evil could be in house. > > And even though evil is not there we, human beings, are really bad at > following rules. Guided editing (something using a DTD, or a XML Schema > compliant document,...) could be the key. > > Even more, there are legal constraints (something like HIPAA and/or HL7 > ) that forces us to have a "fine grained" publishing control system. It > is frequent to be required to control what document, or section of a > document, has been accessed or edited, when, by whom and from where. And > what document or part of a document will be published, when and who has > approved this action. > > Integration of XWiki with other Open Source initiatives seems to be an > answer. For me the question here is if it is better to keep developing > XWiki in a given area, or to join another project as an alternative. For > instance, Pasca Voitot speaks in this same thread about the use of > Magnolia to provide a easily customizable front end for XWiki. The > result as he shows in his site Mandubian is quite good, but it seems to > me that XWiki skins are not so far of being able to allowing something > better!
One thing that should NOT be done, is to use different tools in parallel. One of the big advantages of XWiki is that it allows to build several application in the same place. True, such a small application done with a piece of Velocity and a bit of JavaScript doesn't have all the power and features of a dedicated system, but the advantages are numerous: - one place - one UI - one common set of rules - one principle: the wiki way - for the developers, one API and one common programming paradigm - etc. > It could be said that all these requirements could be only fulfilled by > a top-level commercial software. But we are in the Open Source side of > the moon! Why? This is the subject of a PhD dissertation :-) > > As you say, XWiki apparently has all the required pieces to construct > such a system. I am trying to be as sure as possible that we are on the > right, or at least as right as possible, place. Hm, one thing I'd like to have before going forward with this app is a better event management. The observation component is good, but we're not using it enough. On top of it, we should build a workflow module. Once we have this, writing a publishing control system should be easy. At least a basic one, I don't know what those strange names you used (HIPAA, HL7) imply. About integrating with another tool, this is also a good idea, provided that the tool provides nice APIs, and the tool is complex enough to make a velocity replacement hard to implement. > In brief, we have not a full-featured publishing control system in XWiki > by now. But we do have a great framework and a great community! So, > let's go for it :-) -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
