cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: data goes in, data goes out
Date Fri, 30 Nov 2001 15:23:21 GMT
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="stefano@apache.org"/>
  </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="giacomo@apache.org"
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message