cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: XML Query language
Date Thu, 17 Feb 2000 13:51:16 GMT
Mark Washeim wrote:
> 
> 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.

This is what I _strongly_ believe. 

XML authoring itself won't be easy without WYSIWYG tools, but much more
powerful than what we have today.

Sitemap administration can be easily done with visual tools, even fancy
ones based thru applets and all sort.

But separation of contexts, again is the key. The sitemap might be
verbose and hardly readable... but a tool can change that and still
leave it modificable by simple text editors.

I'm open to suggestions, anyway.
 
> 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 :)

Well, we do not have a "freeze" line, but yes, the earlier the better.
 
> >> 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 :)

well, I was referring to Linus but anyway...

> 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. 

Me too :)

> 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. 

Apache is becoming more and more a brand. Like Linux. It will make
things easier in the future... well, not because we get incorporated or
anything... but because managers will listen and understand.

Cocoon was already cited in a CNN article as "at least in some areas,
ahead of its commercial competitors".

Those are the things that change a manager head. But I perfectly
understand why.

One day, old-time open source geeks will manage companies. Then branding
will have a lot different perspective.

> 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). 

Well, I'm not neglecting... I just don't have the resources :(

> I'm willing and able to release much of this to the community.

And I'm willing to welcome them!!!!

> However, I think that Cocoon is BETTER. Just not as inclusive. So, on top of
> my apology, praise. But, reaity check.

Reality checks are good. Pure innovation is driven by accademic reasons,
but must be shaped by reality checks to be useful.
 
> 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. 

:) I love this sentence.

> 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. 

And I'm listening. 

The question is: does the problem relies on the cocoon model of
contracts or someplace else?

If it's a problem in the contracts model, we change that, otherwise,
it's an implementation detail and we solve it with tools.

> 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? 

Very good question.

Cocoon is trying to engineer web-developing guidelines that have been
used by _many_ for years on _many_ technologies... without patterns. And
it's a pain.

Now, you are asking for sitemap engineering patterns, even before the
sitemap is fully implemented. Gosh, I welcome such deep questions, but I
honestly don't have a clue!

I do see things that are good and things that are not. But this is not
enough to be crystallized into a design pattern. Not yet, at least.

Even for XSP, we have the same problem.

> 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?

How? with clean context separation. And since data creation and
publishing are _not_ the same thing, their control must be separated.

> >> 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.

Great, I'll look forward for that.
 
> I've already made some suggestions (catalogs and 'loose' references). I'll
> formalize that.

Cool because, to be honest, I didn't understand much.
 
> >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! 

Hey, man. This is not _my_ problem.

> 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.

No, you're totally correct. But "front-page crap" and "WebDAV" are
totally different things. WebDAV is standardized by the IETF and it's a
pretty cool idea. At one point, we might even integrate WebDAV features
inside Cocoon if people contribute this... I know Exoffice is thinking
about it.

Anyway, if M$ get WebDAV wrong and add their own extentions, again, this
is _not_ something I can possibly fix.
 
> >> 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. 

Than you have a sitemap design problem!!!

If you need _both_ the PDF version and the original XML version, you do
stuff like

 <process uri="/press-release/*"
  <generator type="file" src="/pr/*.xml"
  <filter>
   <parameter name="stylesheet" value="pr2fo.xsl"/>
  </filter>
  <serializer type="fop"/>
 </process>

 <process uri="/press-release/original/*">
  <generator type="file" src="/pr/*.xml"
  <serializer type="xml"/>
 </process>

and, to be honest, I don't see that much problem.

> 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.

Sorry, man, but you can't even hope that we help you to solve _those_
kind of problems. Accademic or not, that business practice is _totally_
broken. And the amount of money you probably cost them accounts for that
:)
 
> 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 think I don't follow you anymore... you want to use introspection for
what?
 
> 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).

Ok, and we try to see if they already fit into the picture or not.

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




Mime
View raw message