[ZDP] Documentation...PTK, not XML is the answer...

[Jim Salmons]

	I am hearing too many comments that indicate a confusion in object design.
Many people are taught that object are 'things', little balls of structure
and behavior which is good for packaging code for reuse.

	The problem is that 'thing-object' blindness has made for a LOT of BAD
object design. How many of you objectify 'process'.... showing my own
architectural bias for role-based executable models, how many of you
objectify 'actors', 'roles' 'activity' 'task'?

	The original ZDP efforts to address the 'CoolFAQ tool' suffered this same
bias. It was all about the presentation layer, like XML held the answer to a
usable FAQ! In a model-view-controller sense, it was all about the view
layer.

	But a FAQ is a BUSINESS PROCESS with a WORK PRODUCT which is a document.
The document-tail should NOT wag the PROCESS dog.

	If you do a FAQ tool, model and code what this is about. You have a bunch
of roles: QuestionIdentifier, QuestionAsker, SubjectMatterExpert,
TechReviewer, EditorialReviewer, FAQLibrarian, FAQUser, etc.

	The FAQProcess object (almost certainly there is more than one mega-process
object, but let's stick with the big picture here...) knows how to create
the relevant role objects, populate the roles with appropriate
inter-connected Activity objects (Activities being compositions of Task
objects), etc. etc.

	It is the job of a smart desktop framework to generate role-specific views
onto this executing model. Almost all of the old CoolFAQ design document
lived in this presentation space of the FAQUser role and had nothing to do
with the REAL PROBLEM which is the BUSINESS PROCESS of creating and
maintaining a FAQ. It's a people problem, NOT a document design problem. And
no fat, smart domain object design will produce a satisfactory result.

	Tall order, you say. Yes, if you have to write these frameworks from
scratch. I know, I have lead R&D efforts in the development of
Smalltalk-based role-based executable business models. But like anything,
designing and building a good framework is worth every effort in reuse and
extension.

	Now, back to the point. XML is important to us... for data structuring and
presentation concerns. But it is the PORTAL TOOLKIT which holds the key to
our community's effort to produce, maintain and distribute documentation.

	It won't be there out of the gate. It is a diamond in the rough. But it is
the RIGHT STUFF. The challenge will be to see if we can focus and harness
our collective volunteer efforts to take proper advantage of what DC has
wrought.

	ZOPE2/PTK rocks, what are we gonna roll with it?

	Provacatively yours,
	--Jim Salmons--
___________________________________________
   JFS Consulting, a North Carolina nanocorp
   http://jfsconsulting.com/home/nanocorp_welcome.html
   Our web businesses
		http://sohodojo.com
		http://squirrelfeeders.com
		http://popculturestore.com
		http://sailabaco.com