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

Fri Apr 1 11:55:38 UTC 2005

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/

-- 
Sean Wheller
Technical Author
sean at inwords.co.za
http://www.inwords.co.za
Registered Linux User #375355
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20050401/577553b2/attachment.pgp>