Return-Path: 
 <users-return-81151-apmail-cocoon-users-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-users-archive@www.apache.org
Received: (qmail 20298 invoked from network); 22 Jul 2005 21:23:15 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 22 Jul 2005 21:23:15 -0000
Received: (qmail 22951 invoked by uid 500); 22 Jul 2005 21:23:08 -0000
Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org
Received: (qmail 22902 invoked by uid 500); 22 Jul 2005 21:23:08 -0000
Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:users-help@cocoon.apache.org>
list-unsubscribe: <mailto:users-unsubscribe@cocoon.apache.org>
List-Post: <mailto:users@cocoon.apache.org>
Reply-To: users@cocoon.apache.org
List-Id: <users.cocoon.apache.org>
Delivered-To: mailing list users@cocoon.apache.org
Received: (qmail 22889 invoked by uid 99); 22 Jul 2005 21:23:08 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2005 14:23:08 -0700
X-ASF-Spam-Status: No, hits=0.5 required=10.0
	tests=SPF_PASS,WEIRD_PORT
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of lars_huttar@sil.org designates
 208.145.81.85 as permitted sender)
Received: from [208.145.81.85] (HELO mail.link77.net) (208.145.81.85)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jul 2005 14:23:03 -0700
X-Scanned-By: RAE MPP/Clamd http://raeinternet.com/mpp
Received: from [172.20.5.114] (account lars_huttar@sil.org [172.20.5.114]
 verified)
  by mail.link77.net (CommuniGate Pro SMTP 4.1.8)
  with ESMTP-TLS id 79371715 for users@cocoon.apache.org;
 Fri, 22 Jul 2005 17:23:05 -0400
Message-ID: <42E16426.7080105@sil.org>
Date: Fri, 22 Jul 2005 16:24:54 -0500
From: Lars Huttar <lars_huttar@sil.org>
Organization: SIL
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cocoon Users List <users@cocoon.apache.org>
Subject: cinclude doesn't cinclude, only garbles its input
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Dear Cocoonists,

We're getting strange results from cinclude. It's all the more baffling 
because cinclude works fine in many cases.
FYI we've tried this with Tomcat 4.1, Tomcat 5.5, and Jetty, and Cocoon 
2.1.2, 2.1.5.1, and 2.1.7. All give the same results.

When I run the troubled URL, 
"http://localhost:8888/mount/ethnologue/checks/list-tables", the browser 
gives an XML parsing error because the output from cinclude is not 
well-formed XML: most elements have no close tags!

If I do a view-source on the output of the cinclud transform, it looks 
like this:
<table xmlns:cinclude="http://apache.org/cocoon/include/1.0">
  <cinclude:include 
src="cocoon:/checks/count-rows?table=Development_Status">
    <cinclude:include 
src="cocoon:/checks/count-rows?table=Development_Type">
      ...
        <cinclude:include 
src="cocoon:/checks/count-rows?table=Writing_System"/>
(That's really the end!)
Note that only the last element is closed.
    
The pipeline in the sitemap:
      <map:match pattern="checks/list-tables">
        <map:generate src="sources/ethnologue-schema.xml"/>
        <!-- Generate cinclude statements for checks/count-rows from 
<table> elements. -->
        <map:transform src="transforms/list-tables-cinclude.xsl" 
label="raw"/>
        <!-- Process cinclude statements. -->
        <map:transform type="cinclude" label="raw2"/>
        <map:serialize type="xml"/>
      </map:match>

The data in the pipeline before the cinclude transformer 
(check/list-tables?cocoon-view=raw) looks like this:
<tables xmlns:cinclude="http://apache.org/cocoon/include/1.0">
  <cinclude:include 
src="cocoon:/checks/count-rows?table=Development_Status"/>
  <cinclude:include src="cocoon:/checks/count-rows?table=Development_Type"/>
  ...
  <cinclude:include src="cocoon:/checks/count-rows?table=Writing_System"/>
</tables>

In other words, the output of the cinclude transformer is the same as 
its input, except that each <cinclude:include> element becomes a child 
of the previous one. Or to put it another way, all the endElement events 
except one are dropped. There is no processing of the src URLs.
Incidentally, if you run the src URLs on their own, e.g. 
http://localhost/mount/ethnologue/checks/count-rows?table=Development_Status,
they run successfully and produce well-formed XML output:

<table [namespace declarations for xsp, xspdoc, esql, xsp-request]>
  <name>Development Status</name>
  <count>11875</count>
</table>

As I mentioned at the top, cinclude works fine for us in other applications.

Any ideas?

One interesting thing is that if we follow the cinclude transformer with 
an XSLT transformer that simply copies its input, that the XSLT 
transformer's output is
<table xmlns:cinclude="http://apache.org/cocoon/include/1.0">
  <cinclude:include 
src="cocoon:/checks/count-rows?table=Development_Status">
    <cinclude:include 
src="cocoon:/checks/count-rows?table=Development_Type">
      ...
        <cinclude:include 
src="cocoon:/checks/count-rows?table=Writing_System"/>
      ...
   </cinclude:include>
  </cinclude:include>
</table>

In other words, all the unclosed elements get closed. But still no 
indication of why they became children of each other, nor why the 
<cinclude:include> elements didn't get replaced with the output of their 
respective src pipelines.

Any help would be appreciated...
Lars



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