Re: thinking

Am 9.10.2002 11:57 Uhr +0500 uebermittelte ilya folgende Zeilen:
>Hello Wyonacms-users,

Hi Ilya, hello List,

for me it seems a very appealing idea which you put on for 
discussion. Just imagine different versions stuffed with the 
possibility that the software solution might grow as the requirement 
of the client do. I guess we all know the story of the broadening of 
the requirements and the problem that the "solution" can't cope with 
that:

First it's just a simple Web-Site with a couple of pages, then every 
division wants to edit it contents by themself, after short time, 
you'll have to offer PDFs and WML, and at last you'll have to connect 
to a document management or a legacy system.... (YMMV)

Concerning this, wouldn't it be wonderful if the application grows 
with your needs????  I think, yes, it would be...

... however let's get realistic: How does the market around Wyona look like:

- there are a lot of competitors in this market, starting from
   small solutions (ex. FrontPage / GoLive) to medium (typo3, obtree)
   to enterprise sized (ex. vignette)

- Wyona actually is a very sophisticated application, which
    needs a lot of skills to set up and run. I think PHP offers easier
   solutions for small Web-Sites...

- Wyona really uses XML / XSLT to store and present contents. A lot of
   competitors store their information in a SQL-DB.

- Furthermore I see some heavy minuses which could
   turn out against wyona:
     - lack of knowlede with decision-makers
        (what the hence is this XSLT-thing?)
     - lack of documentation
         (complete, covering all aspects of wyona. Also missing is a tutorial,
          which tells you how to set up a wyona web (Ilya, you pointed 
this out in
          your other mail)
     - small installation base
     - lack of references (success stories)
     - lack of portal-readiness (authorisation, access-rights,
       community-tools; allthough cocoon offers some of these, they are
       not fully implemented (yet??))
     - lack of hosting (which providers offers you shared hosting
       w/ tomcat?; most do with PHP or ASP...)

Additionally it is not a SW (or - helas - a product) produced and 
marketed by a big SW-company, steered by marketing goals. Wyona is 
the "Open Source Output" of a commercial firm, realizing projects in 
the CMS field. Allthough, even writing all the above, I think wyona 
is a superb piece of SW. And I would be glad if it would be deployed 
more often. Anyhow, I think the above points are a real drawback for 
suppling a solution for small websites. Guess, a small firm wants to 
set up such a small website whithin a week. Can this be done if there 
is no know how about cocoon / tomcat and XML / XSLT? Concering the 
actual state of the wyona project I've got some doubts! On the other 
hand, for bigger sites, with technically savy people inhouse, wyona 
might be considered as a way to go. Therefore, the big question is, 
how much effort is needed to be able to fullfill the req. of the 
"small website market" . And is this a goal worth to achieve?

In addition to your idea with the editions I tried to specify on a 
high level the different requirements for each case of 
implementation. Sorry, I renamed your ideas, hope, you don't mind...

Basic
-----
- has just a couple of content editors
    (needs just user management)
- no workflow needed
- only pre-publishing revision needed
- contents to be managed:
      - text
      - images (gif / jpg)
- all contents are entered trough a web interface
- goals:
     - easyness of publishing
     - each content editor can put contents online
     - no HTML- or XML-skills for editors
     - no need for centralized webpublishing
     - scheduled publishing of information
     - fixed navigational and taxomectrics structure
     - output of static pages
     - output on channel web
- client doesn't need a dedicated web-server for the live-pages,
   client has a staging- / editing-server in house
- client has following skills within it's staff
     - content editors
         - able to add / edit / delete contents
         - has knwoledge of it's working domain
     - webpublisher
         - design-task (adopting CI / CD, creating images et cetera)
         - can code html
         - is able to edit and change existing XML/XSLT-Files
- following skills are mandatory or external
     - designer
     - XML- / XSLT-specialist
     - Java programmer
     - system manger / webmaster
- doesn't have technically skilled people, might be using lots of support


Intermediate
---------------
- the above
- a couple or more content editors
    (needs users and roles management)
- complex workflow
    (needs workflow-management)
- offering outbound syndication
- channels with FOP like PDF
- communitytools (forum, vote, poll, newsletter)
- goals:
     - content is revised / translated / corrected before it's put online
     - output of static pages
     - offering interaction and not just browsing contents
     - output on channel web, wml, pdf... (multichannel)
- client has a dedicated web-server for live-pages,
   staging- / editing-server in house
- the webmaster and the XML / XSLT specialist is on site
- small developement tasks are done in house

High Level
------------
- the above
- a lot of editors
- syndication (inbound and outbound)
- supports publishing of internal documents (ex. Word or Excel)
- connection to
     - legacy systems
     - file server
     - document mgt sys
     - LDAP (or al) for AAA
- data stored in DB (XIndice, Tamino et cetera)
- goals:
     - contents of different types and for different channels are
       centrally managed
     - output of dynamic pages
     - offering closed user group / portal functions
     - interconnects with different existing systems
- the live website might have to publish dynamically changing
   information; load balancing and fail-over are a clear issue here.

Ufff, a lot of words.... I'm looking forward to the discussion of these...

Markus




>(I have lose original letter, and write again (much more) :) )
>
>Idea is to have differents "edition" of WyonaCMS.
>
>For example "light" "standard" "professional".
>
>
>[ PREAMBULE ]================================================
>
>With internet works different people - they solve different tasks.
>There is "low" task, there is "high" task.
>"Low" mean "simple" but this not mean "not need".
>
>XML+XSLT - is the future of web, it's unambiguously.
>
>And users want to use advantages of XML technologies for their tasks.
>And users have different resources (computer, internet access, knowledge).
>
>
>"Light" task:
>- genetate static html site from XML content with
>   automatic generation navigation (menu),
>- not "high" design site, not "high" content manage.
>Resources:
>- local computer (low performance),
>- dealup internet,
>- access to free hosting,
>- know: XML+XSLT, or not.
>- don't know Java, Tomcat setting, Cocoon2 settings, SQL, SVG ...
>
>"Standard" task:
>- offline site generation,
>- use advantage SVG to have "high" desigh,
>- use advantage of SQL Database to manage content site (use XML-DB,
>   XIndice, f.e.)
>- i.e. "high" design site - designer, "high" site content manage -
>   programmer
>Resources:
>- local computer (medium performance),
>- dealup or direct internet,
>- access to free or paying hosting.
>- know: XML+XSLT, Java not high, SQL, SVG, Cocoon setting, XSP
>- don't know all other :)
>
>
>"Professional" task:
>- on-line site,
>- roles, users ...
>- all power now's wyonaCMS.
>Resources:
>- computer (high preformance) in intranet with Java+Tomcat, or on
>   hosting with Java+Tomcat,
>- direct internet (or not, for intranet using)
>- access to Hosting with Java+Tomcat
>- know: Java "high", all technologies.
>
>
>[ SOLVING ]================================================
>
>And according to this tasks - to make WyonaCMS "editions".
>Different "editions" are destinationed to differents user-layers.
>
>This "tasks" cover different percentage of internet-users (who want to
>take advantage of XML). I think about 80% (light) 15% (standard) 5%
>(professional). Of cause it is rough estimate.
>
>I.e. WyonaCMS now cover 5% of potential users.
>It possible to compare wyonaCMS-now to high flying aircraft, but many
>people walking on earth :)
>
>"Editions" have in mind that user from "light edition" in future time
>may go to "standard", from "standard" to "professional".
>
>(I have paint 2 images about "light" version -
>  http://www.nemilya.narod.ru/wyona/ or
>  http://www.nemilya.by.ru/wyona/)
>
>[ PS ]==============
>
>possible to write XML for "editions":
>
><edition type="light">
>   <task-list>
>     <task name="offline site generation"/>
>   </task-list>
>   <user-knowledge-list>
>     <user-knowledge id="html" percentage="50%"/>
>     <user-knowledge id="xslt" percentage="50%"/>
>   </user-knowledge-list>
></edition>
>
>...
>
>Also possible to write knowledge-list, covering all technologies, which
>are using in WyonaCMS, (and make from this teaching resource, where user
>may see what technologies is in the Internet world):
>
><knowledge-list>
>   <knowledge id="xslt" type="specification">
>     <description>XSL Transformation needed for...</description>
>     <link-list>
>       <link href="http://www.w3.org/TR/xslt" descr="W3C XSL 
>Transformations (XSLT) Version 1.0"/>
>     </link-list>
>     <relation-list>
>       <relation link="Xalan"/>
>     <relation-list>
>   </knowledge>
>
>   <knowledge id="svg" type="specification">
>     <description>Scalagle Vector Graphic needed for ...</description>
>     <link-list>
>       <link href="http://www.w3.org/TR/SVG/" descr="Scalable Vector 
>Graphics (SVG) 1.0 Specification"/>
>     </link-list>
>     <relation-list>
>       <relation link="Batik"/>
>     <relation-list>
>   </knowledge>
>
>   <knowledge id="Java" type="language">
>     <description>Java ...</description>
>     <link-list>
>       <link href="http://www.sun.com/java/" descr="..."/>
>     </link-list>
>   </knowledge>
>
>   <knowledge id="servlet" type="word %)">
>     <description>Servlet is ...</description>
>     <link-list>...</link-list>
>     <relation-list>
>       <relation link="Servlet specification"/>
>       <relation link="Cocoon"/>
>     <relation-list>
>   </knowledge>
>
>   <knowledge id="servlet container" type="word %)">
>     <description>Servlet container needed for ...</description>
>     <link-list>...</link-list>
>     <relation-list>
>       <relation link="Java"/>
>       <relation link="Tomcat"/>
>     <relation-list>
>   </knowledge>
>
>   <knowledge id="Tomcat" type="program">
>     <description>Tomcat is ...</description>
>     <link-list>...</link-list>
>     <relation-list>
>       <relation link="servlet container"/>
>     <relation-list>
>   </knowledge>
>
>   <knowledge id="FOP" type="word %)">
>     <description>FOP ...</description>
>     <link-list>...</link-list>
>     <relation-list>
>       <relation link="FOP specification"/>
>       <relation link="Apache FOP"/>
>     <relation-list>
>   </knowledge>
>
>
>   ...
>
></knowledge-list>
>
>I.e. <link-list> - what is about in web.
>And <relation-list> - relation inside <knowledge-list>.
>
>For example "XML acronyms for Java developers":
>http://www.javaworld.com/javaworld/jw-09-2002/jw-0927-xmlglossary.html
>
>(may by needed to have "parent"-"child" relations,
>like "Servlet container" -> "Servlet" -> "Java program" ...).
>
>Or generally (in ideal) write this in RDF
>(
>   "Tomcat" -[implement]->"Servlet container"-[run]->"Servlet"
>   "Cocoon"-[implement]->"Servlet"
>           -[working on]->"Servelt container"
>   "Servlet"-[are]->"Java byte code"
>   "Java byte code"-[executed by]->"JVM"
>   "JVM"-[there are]->"Sun"
>        -[there are]->"IBM"
>
>   this is only my estimates, in reality I don't know RDF :))
>)
>
>All this I imagine right now - comment (if are) welcome.
>
>This (knowledge-list) is another project, but I think it will be very
>useful to understand what WyonaCMS is, and how WyonaCMS work.
>
>Regards,
>Ilya
>
>
>
>
>_______________________________________________
>WyonaCMS-users mailing list
>[email protected]
>http://mail.wyona.org/cgi-bin/mailman/listinfo/wyonacms-users


-- 
**************************************

Unglaublich, aber wahr: Dilbert lebt!

**************************************