cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] "To Cocoon2 and beyond" :)
Date Sun, 27 Feb 2000 22:35:22 GMT
Mark Washeim wrote:
> -----Original Message-----
> From: Stefano Mazzocchi <>
> To: <>
> Date: 27 February 2000 01:59
> Subject: Re: [RT] "To Cocoon2 and beyond" :)
> >Mark Washeim wrote:
> >>
> >> >NOTE: [RT] stands for "random thoughts", so skip this mail unless you
> >> >really want to. You have been warned.
> >>
> >> Random? :) Hardly, and thanks be to the gods of engineering that it ain't
> >> 'so'! (ok, thank Stefano it ain't so :) )
> >
> >Well, they sounded enough out of context to me to appear totally
> >random... this is how I usually think. This is why people consider me
> >nuts :)
> >
> I have the company rep for being the local madman. My clients are nice to me
> because they believe I might, if provoked, bite :)

I know what you mean... the other Apache guys say that I tend to be
"brutally nonest"... but know what? it pays :)

> >> >2) Enterprise taglibs for XSP
> >> >
> >> >the object -> relational binding logic sucks. This is evident to
> >> >everyone that ever wanted to push an object into a database. People are
> >> >talking about OODBMS... I still have to see one that does what I want,
> >> >but it seems that EJB is what we need.
> >> >
> >> >Something as simple as
> >> >
> >> > ...
> >> > <ejb:bean name="shopping-cart">
> >> >  <ejb:set name="item°>
> >> >   <form:get name="item"/>
> >> >  </ejb:set>
> >> > </ejb:bean>
> >> > ...
> >> > <ejb:commit bean="shopping-cart"/>
> >> >
> >> >now, _THAT_ is something useful... not the SQL crap we have to embed
> >> >into our logic. Sure, if you already have relational data and you want
> >> >something out of it, use donald's sql taglib and you'll be set for
> >> >life... but like if you want to use your DBMS for store ACID
> >> >transactions out of your pages... hmmmm, sql is expensive thing to do
> >> >and, in my opinion, too different from the highly object-oriented Cocoon
> >> >world.
> >> >
> >> >You should have noted, by now, that Cocoon is highly polarized in a
> >> >server -> client direction. While there are a bunch of tools to get data
> >> >out of someplace and presented to you in the fanciest looks, it lacks
> >> >serious attempts to go the other direction.
> >>
> >> We (company called Large Medium, owned by company called Critical Mass)
> have
> >> developed a couple of prototypes using the KBML toolkit available freely
> >> from Inria (Dyade). Namely, EJB Session Bean -> XML -> XSLT -> HTML
> (form)
> >> and HTML (form) -> XML (DOM) -> EJB Session. We've also have an entity
> >> version, though it's 'defunct' already, in our view (always favour the
> >> session).
> >>
> >> DOM 'addressing' we're currently updating to use the most current Schema
> >> specification. We're essentially using a Schema wrapper object composed
> of
> >> Node and Attribute information objects. (sorry, this is a very brief
> >> summary).
> >>
> >> As with other projects we're working on currently, we're going to release
> >> these with an Apache (FreeBSD style) license. In the main, I'm guessing
> that
> >> the prototypes 'may' serve more as a point of departure than anything
> else.
> >>
> >> For the EJB server we've been using Bull's jonas.
> >>
> >> I'll provide links to samples ASAP (which means probably 1 to 2 weeks,
> given
> >> current, mad, production schedules).
> >>
> >> An expression of interest would be great, in the main, if people would
> >> indicate whether they want to see a fully functional demonstration or
> just
> >> design docs, etc. I need to actually assign someone to do the dist, so
> I'd
> >> like to gauge interest....
> >
> >I'd love to give you CVS access and let you do whatever you think it's
> >best.
> >
> >I think you already deserve honorale mention for your very interesting
> >comments and discussions (mainly on the user mail list, for those of you
> >who missed them)... anyway, when the pressure goes away, let me know and
> >we'll arrange that for you and for your group of developers.
> >
> ok, this is probably the best way to go. I think we'll need to do some
> considerable clean-up (library package wise) to push stuff into another CVS
> repository, but that would definately be ideal. We have some fairly banal
> stuff to do (ie, turn into,
> sigh :) ) but should be able to move on this in the coming weeks.

> I'll forward some meta data in the next week or two and then act on
> collective (or other) advice on contributing the effort.


BTW, people, don't fill set aside! Mark will donate us (I'm sure) some
great stuff, but we'll have to improve on it.
> >> >Anyway, Cocoon can do two things:
> >> >
> >> > a) use the RSS info with user preferences to create specific collection
> >> >of resources (sort of a portal building toolkit, which is what the
> >> >JetSpeed project is all about)
> >> >
> >> > b) generate the RSS info out of pages contained inside out of RDF
> >> >metainformation.
> >> >
> >> >While point b) doesn't require any special logic (just a wise knowledge
> >> >of the DTDs involved), point a) requires at least some
> >> >ProducterFromURL... but how do we create a page out of a collection of
> >> >different resources coming from different places?
> >> >
> >>
> >> Again following the lead of Inria research engineers we're building some
> >> 'producers' from URLs. We've been using Info Extractor (package from
> Dyade)
> >> which leans heavily on reg-exp, but provides a very clean means to
> produce
> >> structured output from 'semi-structured' data (ie, especially well suited
> to
> >> tabular data). As with the KBML prototype, we've built servlets which
> permit
> >> us to, a) to the extraction and simply pass through 'raw' data, b) take
> the
> >> output and transform it to XML on the fly. In our frame work context, XSL
> >> transformations are never applied directly (all our tools use wrappering
> >> (decorator pattern) to 'chain' consequtive operations on a stream) so the
> >> objects in question are 'clean'. As above, we'll be happy to supply
> >> examples, given a show of interest.
> >>
> >> In any case, building a producer for cocoon, based on something like the
> >> Info Extractor isn't directly relevant to the aims Stefano is expressing,
> >> it's just an interesting example of a URL type producer.
> >
> >Yes. I've been referring to those kind of Producers as "Adaptors".
> >Oracle Portal-to-Go is heavily based on these (in fact they don't even
> >have our kind of producers but things that grab other data and XML-ize
> >them).
> >
> >I'd love to make a sort-of CPAN collection of Cocoon modules, rather
> >than include all of them into the distribution... but this will happen
> >when the interfaces will stabilize: read after Cocoon 2.0 final is out.
> >
> That's a great idea. While doing research in the last months I did
> installations of XML::Parser, XM L::Generator, XML::Writer, etc from CPAN.
> Any one familiar with the mechanism will recognise the utility of organizing
> the distributions this way. 

To be entirely honest, I don't know anything about PERL... well, I do
know one thing: everybody is exited about it.... so, more suggestions on
this direction will be welcome.

> How about the automated build ?! :)

Look. I've done Apache + JServ + Cocoon installation on my laptop today:
I wish I wrote something like 

 ./configure; make; make install

for Cocoon, but I _DON'T_ want to touch such a thing!!! Can't use
autoconf.. so we should do some special ant task to recognize what
servlet environment we are in. After that, we require to understand
where the conf files are and patch them for our needs....

The solution is a WAR file. The only viable solution.

Unfortunately, we'll have to wait until Tomcat is ready to replace
JServ... and I'm afraid this won't happen soon.
> >> >5) Template Driven Publishing
> >> >
> >> >Which leads us to the my main concern: real life publishing.
> >> >
> >> >All my experience as web designer/engineer comes from content-driven
> >> >publishing and you can tell from what Cocoon is like today.
> >> >
> >> >But people coming from different publishing areas (newspapers) know that
> >> >is the "layout" of the page that drives the process, not the content.
> >> >
> >> >Layout is not style. Layout is about partitioning a 2d space into areas
> >> >and assigning those areas to particular content generators. The Turbine
> >> >framework includes this in detail, but it's limited to a web-oriented
> >> >layout due to HTML constraints.
> >> >
> >> >Now, let us suppose you want to create your web site on a piece of paper
> >> >to show your boss. What do you do first?
> >> >
> >> >You draw rectangles! Here goes the logo, here the news, down here the
> >> >counter, the sitebar with the slashdot news, the weather forecast for my
> >> >town, up on the left the links to the other resources...
> >> >
> >> >You're a programmer, right? You know nothing about style, you can't
> >> >draw, you can't even think of cool graphics or icons or those things...
> >> >but you _do_ see how the layout should look like. You know this by
> >> >experience, you've been surfing the net forever and you know where to
> >> >place the right information... maybe not which font or color or
> >> >background, but you know what should go where.
> >> >
> >> >Everybody does.
> >> >
> >>
> >>  !!! RANT !!!
> >>
> >> I disagree so vehemently with this statement that I'll try to contain
> >> myself. Ignore this block if you're uninterested in theorectical
> >> hectoring....
> >>
> >> Almost everyone, in fact, is TOTALLY ignorant about what should be placed
> in
> >> what position.
> >>
> >> Witness the inumerable interfaces which place navigation bars on the
> >> Even in print publications, you can note a struggle over this question. A
> >> paper like Die Zeit, in my opinion (stress opinion)  does it correctly.
> The
> >> 'lead' article is 'unencumbered' by anthing to it's 'left' on the page.
> When
> >> you pick it off the stand, you read a headline and scan the first
> paragraph
> >> without the movement of your eyes or your attention being impeded by
> other
> >> elements in the layout. ALL the usual 'potted' summaries of contents
> (TOC)
> >> are placed discreetly on the right. I believe that this is not only a
> >> valuable strategy for the sake of reading (attention to content matter)
> and
> >> 'negotiating' (the movement of the eye accross the areas of the page)
> but,
> >> happens, to nicely coincide with heuristics of interface design. Full
> >> circle, at least for the right handed mouse user, the TOC should be
> placed
> >> to the RIGHT, and by the scroll bar or most browsers.
> >>
> >> Ok, I've been bitching at my clients and designers for years about this
> >> issue. I'm not going to opine about it, but my point is that so very few
> >> people know this, that it accounts for much of the disaster we're trying
> to
> >> reel in, now. I mean: if more people understood the issues of the
> >> organization and presentation of information, the WWW wouldn't be a 10th
> the
> >> mess it is now.
> >>
> >> I have the very good fortune of having worked with extrodinary designers
> and
> >> engineers who ARE aware of the issues. Perhaps the one thing which is
> common
> >> to them both is a reading of,
> >> a) Edward R. Tufte's books (Envisioning Information and Visual
> Explanations)
> >> b) good taste :)
> >>
> >> I know that I'm charging at wind mills, as it were, but I want to point
> out
> >> that we shouldn't assume that people's 'intuitive' notions about what
> should
> >> happen in a layout will suffice to produce 'good' (ie, readable,
> functional)
> >> 'interfaces' to some data. In fact, I think that a lack of thought about
> the
> >> implications of a 'presentation' are what have led to much of the mess we
> >> see not only where layout is concerned, but also where the very
> fundemental
> >> Data Structures themselves are concerned. I have a lot of thoughts about
> >> this, but I'm actually working on an essay addressing them, and will
> leave
> >> it out of this context.
> >
> >You got me wrong as you were blinded by things that happen to
> >emotionally involve you :)
> >
> >My statement should read as:
> >
> >Human beings tend to "think" at pages in term of thier visual structure
> >rather then by the marked-up content the page will present.
> >
> >Should _not_ read as:
> >
> >Everybody is able to °think° at the visual structure of pages and go a
> >good job.
> >
> >It reads more or less like:
> >
> >Everybody can write HTML with a few examples and a browser. Few of them
> >can be considered web artists.
> >
> >I don't think that publishing is simple. But much simpler if you can
> >design layout-driven instead of content-driven.
> >
> >Do you disagree with that?
> >
> Hmmm. You're right that the emotional weight of years of fuming impedes my
> sight :)
> However, I'm really not sure that the layout driven approach is suitable for
> anything but the most disciplined or well defined organization. I think that
> you're correct where newspapers are concerned. By the time you hit other
> serials (magazines) I'm not sure, though, should work.

Oh, totally!! If you read carefully my RT, you'll note they "are"
random. I mean: I was thinking at new uses of Cocoon and tested the
architecture with them.

The layout-driven approach outlined some weak points in the XSP
specification, where the XSP content is not there but it's generated by
someone else. Sort of XInclude but I'm questioning if we can "compile"
everything into a single place.

Example: say you have a layout with XSP tags and some inclusion from
other xsp pages. Question: should we compile everything into a single
page or let the inclusion been done dynamicaly at request-time?

In any case, there is no real difference between content-driven and
template-driven, if we think at layout as "content" that must be
processed by cocoon. It just involves another layer of content
> Where corporate information systems or, for instance, scientific journals
> are concerned, well, I think the data driven approach is primary. And I mean
> for the dissemination of information in general, whether you're thinking of
> publishing documents for internal or external use (for scientific journals,
> 'external use' is actually an oxymoron, but, I think my point is still
> valid).

The web was created to be content-driven, a DTD for scientists
homepages. A better way to share documents without the need of complex
software on both server and client side or any special authoring tool.

So, yes, your point is still valid but I would like a publishing
framework to be able to address all needs that require more structured
pubblications... Anyway, decently complex and styled web sites front
pages will be a mix between a simple layout driven approach (sidebar,
banners, logos) and pure-content driven (documents, data)

Anyway, there is no clear cut, so my idea is: provide both ways and let
the users do what they want. I don't think there's nothing wrong with
this approach.

But I'm open to suggestions, expecially if they concern my RT..

> Boils down to the same issues we were discussing vis-a-vis namespaces. I'll
> admit I was taking an unorthodox stance on namespaces (that is,
> distinguishing URIs for concrete instances of content models from the
> namespaces of the content model itself). However, as I've observed before,
> if you don't account for the primacy of the model (a point stefano made)
> you're 'screwed'. That is, if the namespaces accounted for by the
> applications which display and manipulate concrete documents, don't derive
> of a 'mixed model' of the abstract and the concrete (in terms of addressing,
> resolving references) a content management / publishing system will become
> unwieldly, etc.

Which can be easily put as: "if you don't get it, you'll do it wrong".
We'll do our best to provide software, docs and examples on the
technology. But we can't do babysitting :)
> Similarly, finding some balance between the layout driven approach in
> contexts where the work-flow is well established (newspaper publishing) and
> the content model approach where the work-flow is 'less determind' (the
> marketing department, the customer service department and the manufacturing
> department all sharing product specification data within VERY DIFFERENT
> workflows) is very important.

I cannot agree more.
> At the moment, I haven't seen the light on this yet. I also haven't done a
> close reading of the RDF recomendations yet, so I'm probably due for more
> research.

I don't see the light yet either. 
> We still haven't resolved the ongoing disucussion about namespaces yet, and
> I've failed to come up with proper arguements/examples the formulate a
> substantial 'proposal'. I think in the course of the prototyping we're
> doing, with the very mixed (but, to us, well known) data sets, I should be
> able to provide some insight by example in the next couple of weeks
> (possibly take through to the end of march to show the 'broad cross-section'
> of problems.)

I'm look forward to see that.
> Sigh, blah, blah, blah. Sorry I'm sooooo VERBOSE.  In some ICB circles, I'm
> shunned :)

You probably type too fast. use one hand only :)
> What I'm drivin at is that I believe we're on the verge of demonstrating the
> broader problems with a set of applications for a single client which should
> be instructive across the board. Phew.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message