Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 43803 invoked from network); 21 Jan 2000 16:09:08 -0000 Received: from mercury.sun.com (192.9.25.1) by 63.211.145.10 with SMTP; 21 Jan 2000 16:09:08 -0000 Received: from shorter.eng.sun.com ([129.144.125.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07514 for ; Fri, 21 Jan 2000 08:09:02 -0800 (PST) Received: from tallest (tallest [129.144.251.237]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id IAA25409 for ; Fri, 21 Jan 2000 08:08:39 -0800 (PST) Date: Fri, 21 Jan 2000 08:08:39 -0800 (PST) From: "Anil K. Vijendran" X-Sender: akv@tallest To: tomcat-dev@jakarta.apache.org Subject: Re: Why was Jasper support for XML Scripting elements removed? In-Reply-To: <8525686D.0057DB2F.00@d54mta04.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 21 Jan 2000 rubys@us.ibm.com wrote: > Anil K. Vijendran wrote: > > > See Eduardo's mail on this topic (subject: use of xml syntax) on > > tomcat-dev. The idea is mixing both non xml and xml equivalents was not > > intended by the spec and that's exactly what the parser was doing -- > > allowing things to be intermixed. > > I guess I didn't understand the implications of this discussion. There was > a bug with the current implementation - that I can live with. But the fix > was to remove all support for something that is in the spec? I don't think it was that straightforward either. The rationale for the XML equivalents is so that one can construct a JSP page that is well-formed XML. For all the reasons Eduardo describes, the spec is not there yet. The XML equivalents are not exactly aliases for things like <%, <%= etc. They should be used only when the whole page is well-formed XML. And the spec is not yet at a point where a JSP page can be designed to be well-formed XML. (For example mappings need to be clearly.) It seemed like we were trying to support something that wasn't fully cooked in the spec; that's why it was decided we remove it. -- Peace, Anil +<:-)