22 Jul
2009
22 Jul
'09
8:23 a.m.
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi, Sergiu, thanks for the answer.
Sergiu Dumitriu wrote:
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.
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! 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/