giacomo wrote: > > In software terminology, an accumulator is normally called a "store", > > "archive", "cabinet", "safe" and so on with terms that give you an idea > > of "something" that allows you to place information that will > > persistently remain there. > > A Sink as opposed to a Source. But seems to be mutually exclusive as what > Jeremy is proposing with his WritableSource (which IMO isn't a good name > as well as SinkSource).
I like the term "Resource" better since it's direction agnostic. > > So, does this mean we need a "Store"-behaving component in the cocoon > > pipelines? > > > > No, such a store-behaving component would not be distinguishable from > > another transformer. > > I'm not so sure. Today we feed the Serializer with an OutputStream where > it can "store" its output onto (even if this is outward from a requestors > point of view). What about using the same architecture for a > StoringPipeline where the last component (accumulator for now) will be > given a Sink to store the Output it produces. Yes, I agree the storing behavior could be shaped as a serializer but we need some data to come out (see my last post on this thread). > > Thus, a "store" is behaviorally equivalent to a "transformer". > > Well, in term of web applications (and CMS is more a web application that > a publishing system) I'd like to see the inward step separated from the > outward one. We need to be able to perform some logic in between inward > and outward processing. > I don't think you can directly connect the inward > pipe to the outward pipe without giving an Action a chance to act on the > results of the inward pipe. Oh, absolutely, see my writable cocoon: proposal in my last post. > > As Jeremy pointed out, XUpdate is a choice. I must tell you that I don't > > like XUpdate that much, but I admit it's a choice. > > Please share your oppinions on XUpdate with us. I find XUpdate "poor" in terms of design elegance [no offense to those who wrote it!]. It feels like a hack to me and, as other pointed out, a dynamic xpath evaluation in XSLT would make it totally redundant in functionality. Anyway, XQuery is outward-oriented, but is very general. XUpdate is inward-oriented, but it's "update" oriented (at least the name suggests so). The concept is indeed cool and it's absolutely vital to be able to place data *in* a native XML DB (of course, we need that functionality otherwise how do we enter data?), but is this language good enough? A while back, I thought about a language called XInherit which was supposed to apply inheritance behavior to trees. I even talked with Tim Bray about it and he told me that such effort is the ultimate holy grail of the SGML community (they tried to do it with Architectural Forms in the HyTime specification, but lacking the namespace mechanism, the concept became so complex that almost nobody ever understood it!). But they were normally thinking about inheritance at the schema level (XMLSchema, in fact, tries to cover part of this but nobody is happy by the result, ASAIK) Something like this is, IMO, a more elegant solution than XUpdate, because it includes both "inserting" and "updating" in a fall-thru way (instead XUpdate follows an xslt-like declarative approach which I don't find really appealing for such things). For example, consider something like this: article-template.xml <article> <authors> <author name="Stefano Mazzocchi" email="[EMAIL PROTECTED]"/> </author> <body/> <legal>Copyright (c) @@year@@ Apache Software Foundation. All Rights Reserved.</legal> </article> my-article.xml <article xmlns:in="http://blah/xinherit/1.0"; in:inherit="article-template.xml"> <body> <section title="blah"> <para>lskjflkjadlkfjal</para> ... </body> </article> I think you get my point. Now, the above is a very simple example (even if very useful even at this very small degree of limitation!) and it can be shown that XSLT with dynamic XPath evaluation is totally capable of performing such functionality. *but* unlike "XSLT in template mode" which must explicitly indicate where to get the information (there is no automatic fall-thru in XSLT!), this language is much *easier* to conceptually visualize (at least, for me!) and being much more specific might result in easier manageability of structured inheritance. If we also had the ability to replace content, for example <article xmlns:in="http://blah/xinherit/1.0"; in:inherit="article-template.xml"> <authors> <author name="Giacomo Pati" email="[EMAIL PROTECTED]" x:action="replace"/> </authors> <body> <section title="blah"> <para>lskjflkjadlkfjal</para> ... </body> </article> we have a very simple way to perform inserting and updating of semi-structured content at the granularity required and without loosing the structural form of data to submit (which is what I don't find appealing in the declarative mindset that XUpdate has!) To be honest, I never dived into researching a complete algorithmical semantic for such an inheritance language and I believe the functionality should be kept low and, like CSS, avoid entering the world of tree-restructuring that XSLT does (and XUpdate follows). IMO, in fact, you almost never have the need to "restructure" the tree you store into a database, the update is normally that either replaces or adds some nodes. The above example of XInheritance would make this *much* easier than using a collection of explicit XPaths. Hope this concept tickles you as much as it did (and still does) for me. > > > > Or we could use CVS, file systems, relational BLOBs, defragment the > > document into LDAP nodes, FTP, POST it somewhere else, email it to your > > mom, fax it to your brother, print it on a piece of paper for your > > favorite human slave to subsequently crawl... > > > > ... up to you. > > Crys for an abstraction like Prowler!? Maybe, or maybe not. I've been in favor of the adoption of Prowler as an Apache subproject, but I've been really discouradged by the amount of people that use it (virtually zero, AFAIK). Falko and others from the Infozone Group even drove all the way from Germany to talk about this with me, but in all honesty, their view of a CMS is too much of a blackbox to me. And as I wrote before, we need a toolkit more than a black box. I'd like to give Cocoon the underlying functionality of becoming the frontend for your own CMS, rather than plugging Prowler in, or creating a CMS-behaving Avalon component. I'm afraid, to be honest, that no matter how good the CMS is, I'd need something more, but not in terms of storage facility (which is relatively easy), but in terms of workflow management (something that Prowler currently lacks) and stuff like that. What would I gain in having Prowler once I have a writeable dbxml: protocol? > > Jeremy named it "WritableSource" (which is admittedly an ossimoron). > > [havn't found 'ossimoron' in my dict(?)] I meant "Oxymoron" (sorry for my horrible english spelling skills) is a rethoric figure used in litterature: it could be explained as "semantically strident" or "semantically conflicting". It's normally used in litterature to trigger deeper reasoning in the careful reader, but normally makes the reading experience harder, even if it conveys much more information. In ermetic poetry, it's the rule rather than the exception. Here, I was being recursively semantically strident with my irony :) [unfortunately, giving you the semantic context afterwords ruined the joke entirely] -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
