cocoon-users mailing list archives

Hej, all,
>> >
>> >If you think Cocoon is "too" powerful and "too" useful and "too"
>> >expensive... well, nobody forces you to use it. ;)
>>
>> Stefano. This is a glib response and unfair.
>
>You're right. Sorry about that, you come to help us and I blame you for
>that... what an idiot... sorry again :(
Ok, thank you for being honest.
>> The fact is i have the same
>> concern, for the same reason. The introduction of cocoon specific
processing
>> instructions in xml files was the first thing to make me feel wary (since
>> when does my data model for a client document include a cocoon processing
>> instruction?).
>
>And we did the sitemap to overcome that and other design problems.
>
>It might not be perfect, you'll never hear something different from
>here, but it's a try. And, even if you might disagree on that, a serious
>one.
I do think it's a well thought out, methodical approach. It's just a
question of how the theoretical contracts you propose, namely
Management - Content - Logic - Style, can be accounted for in real world
terms.
Perhaps the site-map is the only solution and it will simply require that
authoring tools account for it and allow/facilitate access to the site-map.
I'm still reading throught the Schema, Information Set and Query drafts to
get a grip on whether better proposals aren't already in the works. I hope I
can digest enough quickly to be useful :)
>> Since the site map may pose to be completely untenable under conditions
I've
>> previously alluded to, AND clearly binds you to cocoon, a project being
>> developed by a student, how do you expect people like myself to take
you're
>> being dismissive seriously?
>>
>> I'm accountable for multi-million dollar Total Cost of Ownership
problems.
>> You're leveraging your thesis work to produce software.
>
>There was another european student doing its thesis on open source
>operating system that was considered obsolete right after its start...
>what was the name? can't remember.
My turn to apologize :) I assume you're either referring to Tim Berners Lee?
TBL IS to blame for a lot of the current mess. Have to give him credit for
sticking around to clean it up :)
Certainly, you are in much better company than the likes of Andreeson. Those
who drive software teams to create products which polute the common resource
pool (I'm referring to Netscape html extensions being used by naive users to
create an unusable mess of documents).
>> I'm sorry to bitch, but the reason I use apache and jserv are exactly
>> because I do NOT need to bind myself to jserv when building servlets. In
>> fact, we have a whole application 'framework' that we easily 'port' (ie
>> install) with different web servers and servlet engines without ever
>> changing a line of code.
>>
>> What you propose with the kinds of processing instruction inherent in the
>> site map would render us completely dependant on you. Why wouldn't I just
>> become dependant on
>>
>> com.ibm.b2b.xmlmessage.framework
>>
>> ????
>
>Sorry, but this pisses me off. We give you code, freedom to use it and
>the most open license for commerial products one lawyer can possibly
>dream of... and you go after me because I've done things that others
>couldn't even dream?
>
>How would you react in my shoes?
I apologize. Thank you for your efforts. For years I've been doing what I
can and when in support of the NetBSD foundation (ie, giving my time like
you do with cocoon). And I've been paid back in spades. I really appreciate
your work.
I'm obviously carrying on this discussion for selfish reasons. Namely, I'd
like to be able to use cocoon for my corporate clients. I'm just trying to
elucidate what would stop that from happening and why that's not a good
thing. You wouldn't believe how hard I've had to fight my clients to NOT buy
crap like the Netscape products. Almost every fortune 500 (mercedes benz,
nike, gm) I've worked with specified crap (their IS people are cowardly
software consumers). Everyone wants name brand. Sigh. We're in the middle of
developing 3 systems for content management (using Xalan and Xerces in 2 of
them) which, collectively constitute a 'publishing framework'. Like cocoon,
we're 'sidestepping' security (eg, we're using apache mod_auth_dbm with a
visual front end). Unlike Cocoon, we're not neglecting the content authors
and managers (ie. we have to provide both authoring tools and management
tools). I'm willing and able to release much of this to the community.
However, I think that Cocoon is BETTER. Just not as inclusive. So, on top of
my apology, praise. But, reaity check.
I've taken risks on behalf of my developers to assure that they can REALLY
behave like engineers (ie. as you are :) ) and not just lackies to some IS
department full of people who do not dream in technicolour. The net effect
is, developers who have been able to apply design principles properly on
software projects that see much greater longevity than projects done in the
service of IT departments usually do. I make lots of money fighting upstream
to implement well composed designs. But, I've come to learn to accomodate
what I must (which is much less than the client often wants ! ).
All I care about is a realistic proposition to bridging the contractual
'gap' between domain experts (content / managers ???). I should be asking.
I'm asking. How do we ensure that processing pipelines concieved of for
reasons of application elegance and efficiency don't, by virtue of their
configuration, make 'discrete', interdependant operations on content
impossible? How can two domain experts share their data (the point of xml in
the first place) without each having to work in the others domain? How do we
keep default system behaviours from impinging on people accomplishing THEIR
work?
>> I don't disagree with your stance. I think your egocentricsm is REQUIRED.
>> and in many respects I KNOW that you have a better grasp on the
fundemental
>> issues. However, I also see that you're working from a bit of an ivory
tower
>> (ie. academic) view. I've been working with web publishing problems for 6
>> years now and have to face the simple basic fact that ideals are rarely
>> practicable. And I try a lot harder than most. I've been fighting off the
>> use of JSP for 2 years, because of the very simple fact that it so
basically
>> breaks the very usefull MVC pattern (among other things). But my clients
>> hate me for imposing the additional development time imposed by what I
(and
>> I think you would) consider reasonable design practices.
>
>Hey man, so, please, help us with your experience.
>
>I'm totally serious: I admit that I have limited experience on real-life
>cases. But the amoutn of people around here shows that I've done
>something good... maybe not everything... but at least enough to start a
>community of some sort.
>
>I'd like to think at myself as a catalist, rather then a benevolent
>dictator or anything like that. But one thing is for sure: I want others
>to come and help. I want others to express their opinions and make
>critical suggestions on how to improve the system. I want this project
>to be succesful in any possible way.
>
>And if this is a crime, I'm totally guilty :)
You're right. I'm going to spend all my spare time trying to elaborate
problems with the site map idea. I've read all the developer threads where
site-map is concerned, I'm now going back to the specifications (and
reflections like TBL's). I'm working on 1 framework problem now (with 4
developers) and I'll try to get our reflections to dovetail with the cocoon
discussion.
I've already made some suggestions (catalogs and 'loose' references). I'll
formalize that.
>Of course, not much you can bid your millions on. I would not either.
>
>But what are the alternatives out there?
I wish they were my millions :-) I'm trying to see my way to exactly that
happening. The companies we work with throwing their money behind the Open
Source community and, ultimately, you're ideas. At the very least, if the
content management issues can be solved, I should be able to deliver two or
three large sites using Cocoon for much, if not ALL of the publishing model
(well, we'll have to kick in interfaces for content managers. hopefully we
can do so and contribute them back to the community.
>> >
>> >To avoid to use Cocoon. Well, sorry for being dense, but Cocoon is not
>> >just XML + XSL with a servlet interface. It's a publishing framework.
>> >Otherwise, use XT and live well.
>>
>> I think cocoon is very well designed, and understand the intention of
>> becoming a publishing framework. However, some very obvious things you've
>> missed (addressed, for instance, by the DAV folk) is the whole question
of
>> authentication (addressed by others).
>>
>> And that's not a feature request.
>
>Many believe that it's useless to duplicate existing features, when they
>are orthogonal. It has been shown that WebDAV can work parallely to
>Cocoon... and also that authentication can be provided by apache.
>
>Anyway, I never said that Cocoon is complete.
Ok, but mod_dav, frankly, is more trouble than benefit. And, in fact they
(cocoon and DAV) are not orthogonal when you consider the relationship
between, say, the DAV server and an application like microsoft word equipped
with front page extensions! We're right back at square one if we 'allow'
users using DAV to 'pollute' the collective pool of data models with crap
produced with front page extensions. At least, that's what I'm afraid of.
Correct me if I'm wrong.
>> Ok, I think that, from the vantage point of a document collection managed
>> authoritatively, perhaps by an individual, this is feasible. But how, as
you
>> claim, do individuals content experts in their different domains who must
be
>> able to refer to each others documents deal with the problem that the
>> content they refer to may be mediated in a way that makes it untenable
for
>> them to use the ref?
>
>??? sorry probably my english is too poor for your vocabulary :)
Not your fault. I was unclear. I meant, if user A intends a document to be
rendered as a PDF by the system, by default (URI), and user B can only refer
to said document as a URI, then user B may NOT be able to use the document.
That's precisely the problem that many companies face today. It's gotten so
absurd I've seen the following happen:
Near product launch (car manufacturer, model year), the marketing department
is pushing to produce product specification literature. The form the data is
provided in by the automotive engineers isn't 'suitable'. A desktop
publishing shop 'manually' repurposes a sub-set of the data (flat files from
DB2 are transformed into pdfs representing a sub-set of the data). As the
cars come closer to rolling off the line for the new model year, the data
changes on the manufacturing end. But, there isn't enough time to 'mediate'
the data again (properly). The product literature is full of errata. Sigh.
Life goes on. Incidently, we (web shop) then have to repurpose the bloody
pdfs! Compounding the problem.
That particular problem, I've seen three years running. Gotten to a point
were we're considering writing a bloody DB2 module for the AS400 just to
stop the insanity. Sigh, so much for java. So much for interoperability.
>> I'm referring to a case where, for instance, the URI
>> /some/path/someXML.xml
>>
>> is processed like:
>>
>> <process uri="/some/path/someXML.xml">
>> <match type="language" value="en"/>
>> <generator file="/some/path/index.xml"/>
>> <filter type="xslt">
>> <parameter name="stylesheet" value="FOP.xsl"/>
>> </filter>
>> <serializer type="FO"/>
>> </process>
>>
>> I, unknowingly think it's just an xml file that like the one I'm working
>> from will be styled as html. however, the default processing is handled
by
>> cocoon to produce a pdf. This may be untenable for the particular
>> presentation. All of a sudden, I need to know something about the
>> processing, not just the content model.
>>
>> On the other hand, if I were to 'look-up' a repository of data models and
>> discover an xml document of interest and then could query IT to determine
>> how it could be represented, then I'd be able to use the document
>> effectively. Otherwise, I'm dependant on either instructions from another
>> content expert or an administrative interface to the cocoon engine.
>>
>> I'm not sure if I'm missing something, but that's my 2 bits worth.
>
>I see your point.....
>
>Hmmmm, interesting vision... I'll have to think about it a little...
>
>Do you have any solution to propose? Something like "use the sitemap
>where possible" and fall back on old Cocoon behavior if the URI is not
>matched?
As I suggested earlier, my instincts tell me, use encapsulation. The
'system' from the vantage point of content management should 'mediate' using
the parallel in xml to introspection in java. I'm thinking of BOTH content
model and views.
I'll work on this as hard as I can in the next two or three weeks.
Hopefully, fast enough for cocoon developers.
>You are welcome.. just, please, don't say you are bound to Cocoon, its
>not fair.
>
I'll try to restrict myself to examples of scenarios which we should address
(at least).