DevApp Content Life-cycle [was: Re: Wiki ideas]

Fri Apr 1 15:27:06 UTC 2005

Sean, thanks for a great summary of the state of the art. I'm not 
suggesting we should try to develop something new from a software or 
content-management perspective within the doc-team - I'm suggesting that 
the doc-team lead the search for a good platform, from the existing 
tools out there. It seems you've already made a good start :-)

Sean Wheller wrote:

>On Friday 01 April 2005 11:11, Mark Shuttleworth wrote:
>  
>
>>Let's see what we can get done at UDU, but in parallel, let's see what
>>you guys come up with. 
>>    
>>
>
>Hello Mark, Corey,
>
>Mark you have me thinking, but I am not convinced that doing this kind of 
>project in the space of the doc team is the best thing to do. First, it 
>detracts from our prime focus, to write documents. Second, most of us are not 
>coders. We all have varying skills with Linux but few of us are software 
>architects or coders. Where we can offer the most value is on work process, 
>editing docbook, docbook xml framework and usability. I may be speaking for 
>myself here, but this is how I feel.
>
>On to the issue. 
>
>I am not convinced that the solution we are discussing is suitable for every 
>use case. I think it needs to be made clear that we are not looking for a web 
>building application. I am therefore limiting my use case to the area of 
>documentation. Let me try to make this a bit clearer by stating an  
>objective.
>
>To build a system combining the functionality of document, content and 
>knowledge management. Facilitating easy document creation, revision 
>management, translation, and information access. Implimenting methods based 
>on the separation of concerns. Promoting the maximum level of indirection 
>between the content layer, presentation layer and the capabilities of various 
>user agents and devices used buy the user-audiences and the tasks they 
>perform throughout the information life-cycle.
>
>User Profiling:
>* Developers
>	- Authors
>	- Translators
>* Readers
>	- Anyone who searches/reads support documents
>
>Note: I have purposely tried to make this objective as generic possible in 
>order to allow maximum latitude within the vision engineering that may 
>surround the design of any implimenting solution.
>
>Up until this point, I am not concerned with the application layers used for 
>implimentation. However, I believe that any system aiming to fulfill this 
>objective would have to be xml-centric. Adoption of open standards such as 
>XML and XSLT would therefore form key technology building blocks. 
>
>In our senario we are interested in developing the above outlined 
>functionality around Docbook XML within the context of open source 
>development methodology. K/Ubuntu Linux is our customer. 
>
>While it is certainly possible to incorporate addition formats and contexts, I 
>would like to caution that we refrain from doing so. My reasoning? Well, I 
>feel that for now it is better to avoid becoming 'all encompassing' and risk 
>complication that may slow development and move us away from what we set out 
>to achieve in the first place. Let's not forget why we are even discussing 
>this. We have an itch for a system that combines the power docbook with the 
>ease of use and low barrier to entry experienced under web-based apps, this, 
>inorder to promote document development, translation and management so that 
>K/Ubuntu users may benefit. 
>
>Bite the elephant, one bite at a time. After this, if others want to extended 
>it, then all power and support to them. No doubt, we are on a bleading edge 
>here, but there is a latent demand for such as solution, so I would not be at 
>all surprised if support will be strong.
>
>There is an old saying that goes, "There are many way to skin a cat." The 
>natural inclination, so far, has been to jump at using wiki/plone. Are we 
>sure this is the correct approach? Would it not be prudent to investigate 
>other solutions. There are many open source applications that could serve as 
>the basis for development of such a solution. Each will have their pros and 
>cons, I am sure. Some will require more development in order to attain the 
>objective and others will not.
>
>For my side, as an example, I think that the following solution may be better 
>suited to our requirements.
>
>Web-app
>-----------
>Apache Lenya [1], based on Apache Cocoon [2], running under Tomcat [3] and 
>extended either the Kupu [4] or BXE [5] Editors.
>
>Repos
>-----------
>Lenya has two main repositories:
>1. Live
>2. Authoring
>
>
>Content can move from authoring into Live via the work flow. The authoring 
>repos should be a working copy of svn.
>
>On a sensitive note: There is much religious doctin at Ubuntu with regards to 
>python, gnome and so on. Can we for now put aside religious proclivity and 
>technology preferences and give it an open mind. I think it is better to 
>focus, in order, on the following:
>1. The Problem
>2. The Need
>3. The Users
>4. The Use Cases
>5. The Requirements
>6. The Technologies
>7. The Plan
>
>Let's choose the best technologies to address 1-5 without re-inventing the 
>wheel. May be python is best, maybe java, maybe PHP. Let's see.
>
>  
>
>>In general, I'll be supportive of something that 
>>lets us do wiki-style development of docbook materials, though I know
>>James will refuse to run PHP stuff on our servers.
>>    
>>
>
>While I am not promoting PHP or any other technology for building a web-based 
>front-end, I fail to understand the reasoning behind the word "refuse." There 
>are thousands of systems running PHP, the issue of security lock down should 
>be seperated here. I am reasonably certain that with proper investigation any 
>system can be secured with the proper application of intellect. 
>
>I would like to think that we have open minds and the ability to realize that 
>there are problems with any system. The challenge is for us to understand 
>such problems and develop solutions to solve them. Afterall, that is the 
>basis of software development, find a problem and address it. Most of the 
>problems are already known, what frightens me is the problems of which we 
>have no knowledge. The problems I know pose little risk because I know of 
>them; they can be addressed by simply taking action. Problems we do not know 
>of are the high risk for we know not of them and cannot therefore decide on a 
>course of action.
>
>Well, thanks for your time. Thoughts from all would be appreciated on the 
>discussion and example provided.
>
>Please, if anyone feels offended by anything I have said in this message, 
>believe me it is not done with intent. I like to just say it how I see it. I 
>realize this can make me unpopular at times, but hey my view is just that and 
>carries no pressure on my part to force support for its adoption. Above all I 
>respect discussion and breadth of perspective.
>
>[1] http://lenya.apache.org
>[2] http://cocoon.apache.org/
>[3] http://jakarta.apache.org/tomcat/index.html
>[4] http://kupu.oscom.org/
>[5] http://bxe.oscom.org/
>
>  
>