Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3EDCA16A.1090709@apache.org>
Date: Tue, 03 Jun 2003 08:23:54 -0500
From: Ricardo Rocha <ricardo@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.4) Gecko/20030529
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: C2.0.4: Strange XSLT behaviour in logicsheet when matching text()
  nodes (resent)
References: <A75B2A4B8715D611890B0020482D03D603B0FE2C@cimexc01.ecb.de>
 <3EDC954D.6000908@anyware-tech.com>
In-Reply-To: <3EDC954D.6000908@anyware-tech.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:
> IIRC (but don't ask me why), the XSP engine wraps every text node from 
> the XSP file into <xsp:text> elements.

In the original implementation text nodes were preprocessed and escaped
as string constants in accordance to the rules of the target programming
language. This took place prior to applying the core logicsheet, where
<xsp:text> nodes were to be transparently output as quoted string
constants.

An alternative to this was using XSLT extension functions to perform
string escaping inside the core logicsheet itself. This was rejected at
the time because not all XSLT processors supported extensions and they 
were considered not portable.

Along the way, the XSPMarkupLanguage class was rewritten as a SAX
processor and the language-specific escaping was dropped in favor of...
XSLT extensions inside the core logicsheet :-)

So <xsp:text> is probably a venerable fossil today. That said, "if it
ain't broken..."


Ricardo