Return-Path: 
 <dev-return-71959-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 38591 invoked from network); 5 Mar 2005 10:52:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 5 Mar 2005 10:52:07 -0000
Received: (qmail 54774 invoked by uid 500); 5 Mar 2005 10:52:05 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 54689 invoked by uid 500); 5 Mar 2005 10:52:05 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 54676 invoked by uid 99); 5 Mar 2005 10:52:04 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from essemtepe.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.115)
  by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 05 Mar 2005 02:52:03 -0800
X-Authentication-Info: The sender was authenticated as danielf using PLAIN at
 smtp.nada.kth.se 
Received: from [83.226.250.189] (localhost [127.0.0.1])
	(authenticated bits=0)
	by smtp.nada.kth.se (8.12.10/8.12.11) with ESMTP id j25Apwon016202;
	Sat, 5 Mar 2005 11:51:59 +0100 (MET)
Message-ID: <42298F8A.6040806@nada.kth.se>
Date: Sat, 05 Mar 2005 11:52:58 +0100
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] A Unified Environment Model?
References: <42239FC2.3020503@nada.kth.se>
 <42261931.5060703@nada.kth.se>	 <cc159a4a05030212053e897fc8@mail.gmail.com>
	 <42264C8E.9010207@nada.kth.se>
 <4226C0C3.6010501@apache.org>	 <4226F189.30008@apache.org>
 <4226FD84.1080204@nada.kth.se>	 <4227168E.4070203@apache.org>
 <4227E3B0.1080806@reverycodes.com>	 <422825ED.5090901@apache.org>
 <cc159a4a05030408047698ac01@mail.gmail.com>
In-Reply-To: <cc159a4a05030408047698ac01@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Peter Hunsberger wrote:
<snip/>
> This is more of a RT than anything concrete for or against the ideas
> given so far.
> 
> As I follow this discussion it keeps striking me that we're
> more-or-less reinventing resolvers and sources at a slightly lower
> level.  At one level, people need:
> 
>    protocol://x/y/z
> 
> to resolve to some XML/SAX stream fragment. Now we want  
> 
>   module.x.y.z
> 
> to resolve to something that isn't always XML but can be used to
> create a SAX stream or can be traversed with some kind of expression
> language.

Sources are designed for giving access to streams (and due to eficciency 
reasons SAX streams) and the "object accessors" are intended to give 
access to script friendly POJOs. The streams and SAX streams are 
consumed by parsers or event handling code, while the POJOs are accessed 
by ELs and scripting languages that typically use reflection mechanisms. 
That is quite a large difference.

Even if there are similarities at a more abstract level I don't see what 
we would gain by trying to merge the concepts at the implementation level.

> So on one hand, we've got source resolvers and xpath and on the other
> hand we've got factories (hidden or not) resolving to object modules
> and some expression languages.
> 
> I can't help but have the feeling that if XSLT  was easy we wouldn't
> be having this discussion at all.  Stefano once proposed an alternate
> XSLT syntax, but I think the issues of understanding a declarative
> language wouldn't go away.

XSLT is my number one tool for building Cocoon based webapps, so what 
you suggests certainly doesn't apply to me. IMO the main reason that we 
are not using XSLT for accessing object graphs is that current XSLT 
implementation not are particullary well suited for solving that task. 
XSLT as language could certainly be used for it, but the current 
implementations are specialized for being efficient for SAX inputs. And 
rather hard to use for anything else.

> Personally, I wonder if any of what is being discussed is really
> necessary;

It should be clear be clear from this thread what use cases we have in 
mind. If you have better suggestions on how we can achieve them, please 
go ahead and tell us.

> I'd love to see the Cocoon community put a stake in the
> ground and build a good set of XSLT authoring tools and XSLT function
> and document support capabilities and say "the way to data
> manipulation and transformation with Cocoon is XSLT!"

So would I. But my itch is not strong enough for actually make it 
happen, is yours?

> Given that doesn't seem likely to happen,

You can make it happen if you want to.

> I guess the only thing I can
> suggest here is that everyone should take a step back and make sure
> the existing Cocoon machinery for source resolving and xpath traversal
> isn't re-usable in some way before inventing anything new...

AFAIK there is no existing xpath traversal machinery in Cocoon that we 
could reuse. Part of the proposal is about having such a reusable EL 
mechanism based on the pluggable ELs from template, and about making the 
"script environment" more reusable.

/Daniel