Return-Path: 
 <dev-return-96507-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 48511 invoked from network); 26 Aug 2007 20:08:11 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 26 Aug 2007 20:08:11 -0000
Received: (qmail 895 invoked by uid 500); 26 Aug 2007 20:08:06 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 827 invoked by uid 500); 26 Aug 2007 20:08:06 -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
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 816 invoked by uid 99); 26 Aug 2007 20:08:06 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Aug 2007 13:08:06 -0700
X-ASF-Spam-Status: No, hits=3.2 required=10.0
	tests=SPF_HELO_PASS,SPF_NEUTRAL,URIBL_BLACK,WHOIS_NETSOLPR
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [216.86.168.179] (HELO mxout-04.mxes.net) (216.86.168.179)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Aug 2007 20:08:46 +0000
Received: from [192.168.0.125] (unknown [80.240.191.89])
	by smtp.mxes.net (Postfix) with ESMTP id BCC8AA3228
	for <dev@cocoon.apache.org>; Sun, 26 Aug 2007 16:07:33 -0400 (EDT)
Message-ID: <46D1DD81.2050100@apache.org>
Date: Sun, 26 Aug 2007 22:07:29 +0200
From: Grzegorz Kossakowski <gkossakowski@apache.org>
User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: cocoon-template incompatible change
References: <46CEF3FE.2080701@mobilebox.pl> <46CEFF27.6040602@tuffmail.com>
 <46D05EC6.9010604@mobilebox.pl> <46D06D26.50600@apache.org>
 <46D1C163.8050303@mobilebox.pl>
In-Reply-To: <46D1C163.8050303@mobilebox.pl>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Leszek Gawron pisze:
>> 1. What's the scope of variable introduced by jx:set?
> you are probably asking the wrong question. jx:set always puts a
> variable in current context. The question should be: which
> elements/instructions should trigger a new local context.
> 
> I think new local context should never be introduced for plain xml
> elements (either local or imported, namespaced or not).

Take a look at this code from StartPrefixMapping:

        namespaces.addDeclaration(getPrefix(), getUri());
        objectModel.markLocalContext();
        objectModel.put(ObjectModel.NAMESPACE, namespaces);

What this code does is putting NamespaceTable object (namespaces) on Object Model. It may be used
while some expression deeper in elements hierarchy is evaluated. Even though namespaces are only
supported by JXPath we cannot putting them on Object Model. If we put something, we need to remove
it from Object Model, that's what EndPrefixMapping does:

        objectModel.cleanupLocalContext();

That's why we need to introduce new context when encountering new namespace prefix.

> jx:if, jx:choose, jx:forEach, etc. should create a new local context.

Do you want to say that all instructions that contain other instructions create a new context? If
so, I'm fine with such behaviour.

> jx:call (along with alternative <macroName/> invocation) should create a
> new context that DOES not inherit from parent context (only the
> parameters explicitly passed with <jx:call macro="macroName"
> param1="value" param2="value"/>) should be visible.

That's something new for me but after a while of thinking I agree with you. This means that Call
instruction will need to create it's own instance of ObjectModelImpl class that will be created
every time the call is made. That's not the best option because it couples Template and Object Model
implementation. I must think it over.

> I have no experience in xml namespaces area.
> 
> Are these valid xml files?:
> 
> <root>
>   <foo:foo xmlns:foo="http://foo.org/1.0">
>   </foo:foo>
> 
>   <!-- different namespace, same prefix -->
>   <foo:foo xmlns:foo="http://bar.org/2.0">
>   </foo:foo>
> </root>

Yes, it's valid. It's worth to say that namespace prefix does not matter at all because it's defined
locally and makes it easier to indicate which elements belong to which namespaces.

> <root>
>   <foo:foo xmlns:foo="http://foo.org/1.0">
>   </foo:foo>
> 
>   <!-- namespaced element outside namespace declaration -->
>   <foo:foo>
>   </foo:foo>
> </root>
> 
> If the second one is valid we have to keep all declared namespaces till
> the end of xml file (gets worse for xmls with jx:imports). 

Second file is valid XML but second "foo" element is in the same namespace as root element (empty
namespace) and it's full name is "foo:foo". Lack of namespace declaration makes prefix meaningless
and part of element's name (if prefix is attached to the namespace it's part of element's name also).

Namespace declarations are not available to sibling elements.

> Unnecessary
> namespaces are cleared anyway by a filter:
> 
> XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(new
> RedundantNamespacesFilter(this.xmlConsumer));
> 

Leszek, you are mixing two things:
1. SAX events declaring namespaces pushed down the pipeline that you say are filtered out.
2. Namespaces declaration put on Object Model that are used solely for JXPath purpose and have
nothing to do with SAX events.

> Once again: the contract of jx:set is clear. On the contrary we have
> inconsistent context creation contract for all other jx:* instructions.

>From ObjectModel point of view everything is fine. StartPrefixMapping puts something on ObjectModel
that will need to be cleaned up later on so it needs to create local contexts.

However, what we want to is to attach variable to context upper in hierarchy. I'm thinking about
named contexts. For example, jx:if could create new local context this way:

objectModel.markLocalContext("jx:instruction");

Then in jx:set we could use:

objectModel.put("variable_name", variable, "jx:instruction");

so object model would attach this variable to the first context with name "jx:instruction" found
when searching the context hierarchy.

I'm not particularly happy with such approach because it pollutes Object Model API but I couldn't
come with something more elegant.

Thoughts?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/