Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B334A70.4020408@hartle-klug.com>
Date: Fri, 22 Jun 2001 15:38:56 +0200
From: Michael Hartle <mhartle@hartle-klug.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 0.8) Gecko/20010215
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Alternative Solution to XSP
References: <3B324086.513A7DE7@apache.org> <3B3332DA.40807@hartle-klug.com>
 <3B333F7C.B824DAFD@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Berin Loritsch wrote:

> Michael Hartle wrote:
> 
>> What am I missing that might screw such a setup ?
> 
> 
> Data driven sites.  There has to be a way for business anylists to alter
> things like "What is a prompt called?", "What are the instructions for this
> form", and "What is the text of the help for this entry?" without screwing
> up standard layout conventions as well as how the information is pulled
> from the persistence layer.

I yet fail to see the problem; the consultant has to help the customer 
to specify the requirements when setting up a complex Cocoon2 site, and 
your examples would be a such a requirement in the business analyst 
situation. The question "What is the text of the help for this entry" 
for example could be solved by the means of tags for form-development. 
This could result into something like

   <form:entry>
       <form:prompt>Please enter your name</form:prompt>
       <form:instruction>Name, Surname</form:instruction>
       <form:help>Your name is required if you are interested in opening 
a bank account</form:help>
   </form:entry

If the layout convention for a site has been thought through, thinking 
on how to visualize such forms with all possible gimmicks and extras, 
the resulting setup of generators and transformations from this thought 
process will do. Perhaps you can give a more detailed example so we 
could discuss this issue in-depth ? The question *how* information is 
pulled from the persistence layer cannot and can never be solely put 
into the hand of a non-technicial; the consequences start at people 
pulling information from the wrong resources in the best case and lead 
to unspeakably worse things.

> The real danger is when the Business Analyst *thinks* they know something
> about the system.  In smaller companies like mine, we all know what is going
> on with a project.  If he (thinking he is helping) adjusts a SQL statement
> that is embedded, the app is broken.  The extent of the fix may be easy to
> locate or difficult depending on what has changed (I've seen a wrong sort order
> screw up expected results--esp. in complex joins).

This example is critical since the business analyst *thinks* he knows 
something about the system *and* has direct access to the plain text 
XML. What if the business analyst forgot to close a tag somewhere ? What 
if the business analyst added a HTML entity for the copyright symbol, 
invalid in XML because undeclared ? What if the business analyst screws 
up with character encoding ?

As tracking errors in XML files via Cocoon is sometimes a nightmare at 
best, I guess that the topic of malicious users having direct access to 
plain XML is ten times worse, so non-technicials *have* to be limited 
using applications creating error-free XML for them. In criticial 
environments you will be forced to work with versioning support so you 
can turn back time to the point where life still was good.

> What I am saying is typically what happens with XSP in general is that logic
> creeps into the page even if it is for something simple.  As soon as that
> happens, it is not suitable for a Business Analyst.  Besides Softquad XMetaL
> is not that good with namespaces--esp. when you are creating new documents.

SoftQuads limitation regarding namespaces is yet to be removed, thats 
right, but according to the DOM1 specification, compliant software has 
to consider <my:test/> as a tag with local name "my:test", allowing 
documents with namespaces at least to be used. There is still Arbortext 
Epic, on which I yet had no chance to put my hands on, but the price tag 
here is even worse.

> We need to come up with something scalable, that works for every company
> from open source project to fortune 500.

We are in need of an open source editing alternative, taking XML to 
word-processors for the masses. There are many small projects on 
Sourceforge and I had my still uncompleted one making XML directly 
editable (with CSS stylesheets for display details) like within 
Microsoft Word with semantic attributes to be given, but those efforts 
are all in their early early early beginnings and uncoordinated in 
contrast to Cocoon2. Make this XML/CSS2 word processor an quality open 
source applet running on all browsers and life would be perfect ;)

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org