File: wd-xsp.html

package info (click to toggle)
cocoon 1.8-1
links: PTS
area: contrib
in suites: woody
size: 12,016 kB
ctags: 3,793
sloc: xml: 16,682; java: 8,089; sh: 174; makefile: 61
file content (633 lines) | stat: -rw-r--r-- 27,164 bytes
<HTML><HEAD><TITLE></TITLE><LINK href="resources/simple.css" rel="stylesheet" title="Simple Style" type="text/css"></HEAD><BODY><P class="legal">Cocoon Documentation</P><H1 class="title"></H1><SPECIFICATION>
 <TABLE class="header"><TR><TD><B>Authors</B></TD></TR><TR><TD><B>Stefano Mazzocchi</B> - stefano@apache.org</TD></TR><TR><TD><B>Ricardo Rocha</B> - ricardo@apache.org</TD></TR><TR><TD><B>Status</B></TD></TR><TR><TD><B>Working Draft - 2000-01-09</B></TD></TR><TR><TD><B>Notice</B></TD></TR><TR><TD>
    This is an Apache Working Draft for review by all interested
    parties. It is a draft document and may be updated, replaced, or obsoleted by other
    documents at any time. It is inappropriate to use Working Drafts as reference material or
    to cite them as other than &quot;work in progress&quot;. This work is part of the Apache Cocoon Project
  </TD></TR><TR><TD><B>Abstract</B></TD></TR><TR><TD>
    This document specifies an XML namespace that addresses a complete
    region of web publishing, that of logic-based, dynamic content generation. This language
    is introduced to fill an existing gap between the W3C specifications and working draft and
    the increasing demand for a flexible server side approach based on the new XML paradigm.
  </TD></TR></TABLE>
 
 <BODY>
  <H1>Introduction</H1><DIV id="s1">
   <P>This document specifies both an XML document type definition and a development
   methodology to generate dynamic XML by server side processing of client's requests. Such a
   specification is useful to define an open and standard way to develop and maintain dynamic
   XML server pages. The technology described in this document was designed to complete the
   XML-based publishing framework defined by the Cocoon Project and it's mainly targeted
   on this project, even if the final goal of this effort is to submit a request to a standard
   body (such as W3C) for final recommendation.</P>
   
   <H2>Origins</H2><DIV id="s2">
   <P>The need for an open language to standardizing server side programmatic XML generation
  was observed when XML-based web publishing frameworks emerged and no available technology
  was detailed, stable, useful and open enough to be used. XSP, by mixing Turing-complete
  programming logic with page content, provide a flexible yet fully portable and extensible
  way to develop dynamic XML content. Moreover, being completely XML-based, XSP are fully
  integrated with XML-based web architectures that allow XSL-transformation to obtain the
  context separation that is needed for complex sites to increase their management
  parallelism.</P>
  
  <P>Being based on an XML paradigm from the beginning, XSP don't suffer limitations other
  server pages technologies do: the ability to XSL-transform XSP directly and recursively
  allows a more compact and precise DTD to be designed since content/logic/style separation
  is performed by the architecture and not by the language itself. For this reason, XSP are
  completely transparent to the namespaces/document-types used.</P>
   </DIV>
 
<H2>Layer Separation</H2><DIV id="s2">
  <P>Being a rather complex technology, the XSP specification will be separated into layers.
  These layers will have different goals and restrictions and will allow faster development
  cycles and a better defined development model. Every layer will define its own document
  type definition which may extend the one of the previous layer or completely change it,
  depending on layer goals. Layers should be seen as levels of abstraction, much like
  programming languages range from higher-levels to lower-levels.</P>
</DIV>

<H2>General Goals</H2><DIV id="s2">
  <P>Following is a summary of the design principles governing the general XSP specification:</P>
  <OL>
   <LI>should integrate completely with existing W3C recommendations and working drafts</LI>
   <LI>should be programming language independent</LI>
   <LI>should be aimed to programmers but should be relatively easy to understand</LI>
   <LI>should allow pages to be compiled (into Java servlets or other equivalent technology)</LI>
   <LI>should not aim to replace existing technologies</LI>
   <LI>should be document oriented</LI>
   <LI>should allow easy reusability of page code</LI>
   <LI>should allow complete separation of knowledge contexts (content, logic and style)</LI>
   <LI>should be transparent to all but page programmers</LI>
   <LI>specification should be open to all but controlled directly by the Cocoon Project</LI>
  </OL>
</DIV>

<H2>Layer 1 Goals</H2><DIV id="s2">
  <P>Following is a summary of the design principles governing the Layer 1 of the XSP
  specification:</P>
  <OL>
    <LI>should define the complete element set</LI>
    <LI>should be aimed to machine generations so:
     <UL>
      <LI>reducing the number of elements to a minimum is of maximal importance</LI>
      <LI>verbosity of the generated documents is of minimal importance</LI>
     </UL>
    </LI>
    <LI>should be human readable/editable so:
     <UL>
      <LI>terseness and readability are of maximal importance</LI>
      <LI>indenting and formattation are of maximal importance</LI>
     </UL>
    </LI>
    <LI>should be possibly XSLT transformed directly into programming language source code</LI>
    <LI>should define the relations to the programming languages (object models, variable scopes)</LI>
  </OL>
</DIV>

<H2>Layer 2 Goals</H2><DIV id="s2">
  <P>Following is a summary of the design principles governing the Layer 2 of the XSP
  specification:</P>
  
  <OL>
   <LI>should define a human oriented element set</LI>
   <LI>should be aimed to human generations so:
    <UL>
     <LI>reducing the number of elements to a minimum is of minimal importance</LI>
     <LI>reducing verbosity of the documents is of maximal importance</LI>
    </UL>
   </LI>
   <LI>should be aimed to medium-low knowledged programmers:
    <UL>
     <LI>automatization of complex operations is of maximal importance</LI>
     <LI>tendency to hide page logic is of maximal importance</LI>
    </UL>
   </LI>
   <LI>should be possibly XSLT transformed into XSP Layer 1 documents</LI>
  </OL>
</DIV>

<H2>Final Goals</H2><DIV id="s2">
  <P>The XSP specification would eventually evolve into a single specification with a single
  document type definition. This will happen when the working draft phase will be terminated
  and all involved parties will agree on the specification stability. The Layer 1 will be
  the first to be developed and tested in a working implementation. Subsequent layers will
  probably need several evolution stages to reach their final shape.</P>
</DIV>

<H2>Relationship to Existing Standards</H2><DIV id="s2">
  <P>Three standards have been especially influential:</P>
  <DL>
    <LI><STRONG>JSP</STRONG> - defines a way to embed programmatic logic into web documents.</LI>
    
    <LI><STRONG>XSLT</STRONG> - defines a way to transform XML documents.</LI>
    
    <LI><STRONG>XML</STRONG> - defines a flexible still highly structured paradigm for web
      content generation and distribution.</LI>
    
  </DL>
  <P>Many server side dynamic web content generators have been evaluated and confronted,
  especially WebMacro and GSP.</P>
</DIV>

<H2>Terminology</H2><DIV id="s2">
  <P>The following basic terms apply in this document:</P>
  <DL>
    <LI><STRONG>document</STRONG> - 
      a document is the final result of the client request phase and they can be obtain from a
      single file that is read from disk/cache or by processing several ones. Documents are said
      static if their content doesn't change with user request parameters nor time.
      Documents are said dynamic if they do.
    </LI>
    
    <LI><STRONG>page</STRONG> - 
      a page is the entity that is requested by the client and drives the document creation
      process. In the simplest case, a document is created reading the page and sending it
      directly without further processing. In case of compiled pages, a binary object is
      executed and it's content is used as page content. Pages are said compiled if
      they are translated into binary code. Note that compiled pages may be created from normal
      pages the first time the page is requested and executed as binary code in further requests
      for performance reasons.
    </LI>
    
    <LI><STRONG>sheet</STRONG> - 
      a sheet is the processing unit of the document creation chain. Each sheet is a file and
      they contain the instructions to transform the requested page into the document sent to
      the requesting client. Sheets are said style sheets if they are the last of the
      chain and no further processing in performed, logic sheets if they contain XSP
      elements. Both types are said transformation sheets since they contain XSLT
      elements.
    </LI>
    
    <LI><STRONG>document type</STRONG> - 
      a document type is a unique name that identifies the type of the document being
      generated. This term has the same meaning as in the XML specification. Note how a document
      has only one document type but this could change during processing since transformation
      sheets allow the transformation from one document type into another.
    </LI>
    
  </DL>
</DIV>
</DIV>

<H1>XSP Syntax and DTD</H1><DIV id="s1">

<H2>Defined External Entities</H2><DIV id="s2">

  <P>The XSP specification defines some external entities that may be used to reduce the
  verbosity of XSP document, allowing the inclusion the default DTD via entity mapping. The
  standard way to include the XSP DTD into XSP documents is:</P>

<PRE>
&lt;!DOCTYPE page PUBLIC 
   &quot;-//Apache//DTD XSP//EN&quot; 
   &quot;http://www.apache.org/1999/XSP/Core&quot;
&gt;
</PRE>

</DIV>

<H2>The XSP Layer 1 Document Type Definition</H2><DIV id="s2">
  <P>The XSP DTD was designed with simplicity in mind. The number of elements and attributes
  was reduced to a minimum to allow a fast and easy learning process. On the other hand, no
  special helper elements were defined in Layer 1 to reduce the spec development time and to
  favor early feedback from both implementers and users.</P>
  
  <P>The following is the complete DTD. It must be noted that this DTD can hardly be used
  (alone) to validate any XSP due to the fact that XSP are namespace orthogonal and are
  designed to include as content mark-up elements that belong to other namespaces.
  The XSchema effort will allow multi-namespace validation.</P>

<PRE>

&lt;!ENTITY % elements &quot;xsp:expr | 
                     xsp:element | 
                     xsp:pi | 
                     xsp:comment&quot;&gt;

&lt;!ELEMENT xsp:page (xsp:structure?, xsp:logic?, xsp:content)&gt;
&lt;!ATTLIST xsp:page
  language CDATA #REQUIRED
  indent-result (yes|no) &quot;no&quot;
  xmlns:xsp CDATA #FIXED &quot;http://www.apache.org/1999/XSP/Core&quot;
  xml:space (default|preserve) &quot;preserve&quot;
&gt;

&lt;!ELEMENT xsp:structure (xsp:dtd?, xsp:include*)&gt;

&lt;!ELEMENT xsp:dtd (#PCDATA)&gt;
&lt;!ELEMENT xsp:include (#PCDATA)&gt;

&lt;!ELEMENT xsp:content (#PCDATA | xsp:logic | %elements;)*&gt;

&lt;!ELEMENT xsp:logic (#PCDATA | xsp:content | %element;)*&gt;
&lt;!ATTLIST xsp:logic xml:space (default|preserve) &quot;preserve&quot;&gt;

&lt;!ELEMENT xsp:element
          (#PCDATA | 
          xsp:attribute | 
          xsp:element | 
          xsp:logic |
          xsp:expr)*&gt;
&lt;!ATTLIST xsp:element
          name CDATA #REQUIRED&gt;

&lt;!ELEMENT xsp:attribute (#PCDATA | xsp:expr)&gt;
&lt;!ATTLIST xsp:attribute 
          name CDATA #REQUIRED
          xml:space (default|preserve) &quot;preserve&quot;&gt;

&lt;!ELEMENT xsp:pi (#PCDATA | xsp:expr&gt;
&lt;!ELEMENT xsp:comment (#PCDATA | xsp:expr)&gt;
&lt;!ELEMENT xsp:expr (#PCDATA)&gt;  

</PRE>
  
</DIV>
</DIV>

<H1>Example of Usage</H1><DIV id="s1">
  <P>Consider the following XML source document:</P>

  <PRE>
    &lt;?xml version=&quot;1.0&quot;?&gt;

    &lt;page&gt;
      &lt;title&gt;A Simple XSP Page&lt;/title&gt;
      &lt;p&gt;Hi, I've been hit &lt;counter/&gt; times.&lt;/p&gt;
    &lt;/page&gt;  
  </PRE>

  <P>This simple example shows the power of content/logic/style separation. While the <CODE>&lt;title&gt;</CODE>
  tag has a very special meaning in the <EM>page</EM> document type, indicating the page
  title, the <CODE>&lt;counter&gt;</CODE> element is needs to be dynamically substituted by
  the number of times the document has been requested. The logic that performs such behavior
  is included in tag itself, but unlike other existing server side technologies, the
  behavior is not defined in the page itself, but on the logic sheet that is applied to
  evaluate this behavior. In fact, the same page may have a totally different behavior
  depending on the logicsheet that is applied to the page. Note that it's beyond the scope
  of this specification to define a way to associate transformation sheets to pages. The
  associated logicsheet that uses the Java language as logic definition may look like:</P>
  
<PRE>
&lt;?xml version=&quot;1.0&quot;?&gt;
&lt;xsl:transform
 xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Tranform&quot; 
 xmlns:xsp=&quot;http://www.apache.org/1999/XSP/Core&quot;
&gt;
   
 &lt;xsl:template match=&quot;page&quot;&gt;
  &lt;xsp:page language=&quot;java&quot;&gt;

   &lt;xsp:structure&gt;
    &lt;xsp:include&gt;java.lang.*&lt;/xsp:include&gt;
   &lt;/xsp:structure&gt;
     
   &lt;xsp:logic&gt;
    private static int counter = 0;
         
    private synchronized int currentCount() {
      return ++counter;
    }
   &lt;/xsp:logic&gt;
      
   &lt;xsp:content&gt;
    &lt;page&gt;
     &lt;xsl:apply-templates/&gt;
    &lt;/page&gt;
   &lt;/xsp:content&gt;
  &lt;/xsp:page&gt;
 &lt;/xsl:template&gt;
    
 &lt;xsl:template match=&quot;counter&quot;&gt;    
  &lt;xsp:expr&gt;currentCount()&lt;/xsp:expr&gt;
 &lt;/xsl:template&gt;

 &lt;!-- Transcribe everything else verbatim --&gt;
 &lt;xsl:template match=&quot;*|@*|comment()|pi()|text()&quot;&gt;
  &lt;xsl:copy&gt;
   &lt;xsl:apply-templates/&gt;
  &lt;/xsl:copy&gt;
 &lt;/xsl:template&gt;
&lt;/xsl:transform&gt;
</PRE>
    
  <P>After applying the above logic sheet, the resulting document would be equivalent to the
  following:</P>
  
<PRE>
&lt;xsp:page 
 result-ns=&quot;http://www.dummy.org/SimpleHomepageDTD&quot;
 language=&quot;java&quot;&gt;

 &lt;xsp:structure&gt;
  &lt;xsp:include&gt;java.lang.*&lt;/xsp:include&gt;
 &lt;/xsp:structure&gt;

 &lt;xsp:logic&gt;
  private static int counter = 0;
        
  private synchronized int currentCount() {
    return ++counter;
  }
 &lt;/xsp:logic&gt;

 &lt;xsp:content&gt;
  &lt;page&gt;
   &lt;title&gt;A Sample XSP Page&lt;/title&gt;
   &lt;p&gt;
    Hi, I've been hit 
     &lt;xsp:expr&gt;currentCount()&lt;/xsp:expr&gt;
    times.
   &lt;/p&gt;
  &lt;/page&gt;
 &lt;/xsp:content&gt;
&lt;/xsp:page&gt;     
</PRE>
  
  <P>At this point it's worth to note that from an XSP point of view, there is 
     no difference in how the XSP page was created, either directly written or 
     created with n levels of transformation. So, independently of whether an 
     XSL stylesheet or a special algorithm was used to generate the final 
     source code, it may look like this [<EM>Note</EM>: many key issues regarding 
     servlets were omitted for simplicity and this example must not be 
     considered mandating as a way to format XSP into servlet source code]</P>
  
<PRE>
// package automatically created from the full request URL...
package org.apache.cocoon.xsp.example;

// packages imported automatically by source code generator
import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.w3c.dom.*;
  
// packages imported due to XSP structure
import java.lang.*;

// class name automatically created from the 
// request URI file name...
public class Counter extends HttpServlet {

  public void init(ServletConfig config) 
    throws ServletException
  {
    super.init(config);
  }

  private static int counter = 0;
            
  private synchronized int currentCount() {
    return ++counter;
  }
 
  public void service(HttpServletRequest request, 
       HttpServletResponse response) throws IOException 
  {
    Document document = parser.createEmptyDocument();
    Element root = document.createElement(&quot;page&quot;);
    document.appendChild(root);
  
    Element element_1 = document.createElement(&quot;title&quot;);
    root.appendChild(element_1);
    Text textNode_1 = document.createTextNode(&quot;A Sample XSP Page&quot;);
    element_1.appendChild(textNode_1);

    Element element_2 = document.createElement(&quot;p&quot;);
    root.appendChild(element_2);
    Text textNode_2 = document.createTextNode(&quot;Hi, I've been hit &quot;);
    element_2.appendChild(textNode_2);
    StringBuffer buffer_1 = new StringBuffer.append(currentCount());
    Text textNode_3 = document.createTextNode(string_1.toString());
    element_2.appendChild(textNode_3);
    Text textNode_4 = document.createTextNode(&quot;times.&quot;);
    element_2.appendChild(textNode_4);
  
    // Produce generated DOM tree on output as an XML stream
    ((Child) document).toXMLString(response.getWriter());
  }
}  
</PRE>  
 
  <P>Note that in this example the XML document is being generated as a <EM>stream</EM>
  but a DOM tree is used to create it. The DOM tree can't be passed directly to
  the servlet engine for further processing because the current servlet specification
  (2.2) does not allow for content generation in a format other than a stream. A rather undesirable consequence
  of this is that the resulting XML document would need to be re-parsed in case a final XSL
  stylesheet or other post-transformation must be applied.</P>
  
  <P>To solve this problem and speed up the execution on server side XML
  processing, the XSP can be compiled into something like this:</P>

<PRE>
// package automatically created from the full request URL...
package org.apache.cocoon.xsp.example;

// packages imported automatically by source code generator
import java.io.*;
import java.util.*;
import org.xml.sax.*;
import org.apache.cocoon.*;
  
// packages imported due to XSP structure
import java.lang.*;

// class name automatically created from the 
// request URI file name...
public class Counter extends AbstractProducer {

  private static final char[] chars_0 = 
   {'A',' ','S','i','m','p','l','e',' ','X','S','P',' ','P','a','g','e'};
  private static final char[] chars_1 = 
   {'H','i',' ','I','\'','v','e',' ','b','e','e','n',' ','h','i','t',' '};
  private static final char[] chars_3 = 
   {' ','t','i','m','e','s'};

  private static int counter = 0;
            
  private synchronized int currentCount() {
    return ++counter;
  }
 
  public void toSAX(Request request, DocumentHandler handler) 
    throws SAXException 
  {
    handler.startDocument();
      handler.startElement(&quot;page&quot;, null);
        handler.startElement(&quot;title&quot;, null);
          handler.characters(chars_0, 0, 17);
        handler.endElement(&quot;title&quot;);
        handler.startElement(&quot;p&quot;, null);
          handler.characters(chars_1, 0, 17);
          String string_0 = (new StringBuffer.append(
            currentCount()
          )).toString();
          int string_0_length = string_0.length();
          char[] chars_2 = char[string_0_length];
          string_0.getChars(0, string_0_length, chars_2, 0);
          handler.characters(chars_3, 0, 6);
        handler.endElement(&quot;p&quot;);
      handler.endElement(&quot;page&quot;);
    handler.endDocument();
  }
}  
</PRE>

  <P>The above shows one of the best features of XSP: output independence.
  Since the output objects are not accessible directly from the internal page
  logic (unlike other similar technologies, such as JSP), the page compiler can
  choose between a great variety of possible ways to generate and forward the
  page content. In fact, while the first example uses DOM as a construction set
  and a stream as output method, the exact same page is compiled in the second
  example to use a SAX event-based model and a document handler as output.</P>
  
  <P>Finally, It is beyond the scope of this specification to define how XSP are translated
  into binary code and how these interact with the publishing frameworks that handle
  them, but it is mandated that this should be completely transparent to the
  page programmer and an XSP page should behave exactly the same (modulo
  performance) in every XSP engine.</P>
</DIV>

<H1>XSP and JSP</H1><DIV id="s1">
  <P>XSP and JSP might appear as overlapping at a first glance since they both:</P>
  
  <UL>
    <LI>follow the <EM>compiled server pages</EM> model, allowing server pages to
      be compiled into binary code for faster execution.</LI>
    <LI>can be parsed and validated by regular XML parsers</LI>
    <LI>can be transformed by XSLT processors</LI>
    <LI>aim to programming language abstraction</LI>
  </UL>
  
  <P>While these are very important points were the two specifications <EM>do</EM>
  overlap, there are significant differences described hereafter.</P>

<H2>Output Exposure</H2><DIV id="s2">
  <P>In all different server pages technologies, some data regarding the status
  of the resource are available to page logic. Since JSP follow the Servlet API
  model, expecting JSP pages to be compiled into servlets, the same data
  available to servlet is available to page logic. This allows the page logic to
  obtain access to the output channel (being either an OutputStream or a Writer
  for servlets).</P>
  
  <P>While this is not a problem for normal web operation when no further server
  side processing is performed, for XML generation (where further server side
  processing may be needed, depending on client capabilities) the Servlet/JSP
  limitations impose on the server pages engine a parsing stage that is
  completely avoided in XSP.</P>
  
  <P>In fact, in XSP, page logic has <EM>not</EM> direct access to the output
  channel and it's the page compiler responsibility to choose the preferred
  method to compile the page, depending on processing needs and server
  requirements.</P>
  <P>It should be noted how XSP spec provides three different contexts: <CODE>content</CODE>,
  <CODE>logic</CODE> and <CODE>eval</CODE>. These three contexts never overlap
  since <CODE>content</CODE> is used to create static markup content, <CODE>logic</CODE>
  to indicate programming logic and <CODE>eval</CODE> to bridge the two domains,
  allowing a logic component to be evaluated without exposing the output channel
  to the logic context.</P>
  <P>This is a very significant difference since it allows XSP page compiler to <EM>hardcode</EM>
  pre-parsed XML content thus removing the request time parsing overhead that
  JSP always require.</P>
</DIV>

<H2>Page Readability</H2><DIV id="s2">
  <P>For these reasons, XSP, unlike JSP, uses the XML feature of <EM>syntax
  orthogonalily</EM> that allows almost any programming language code to be
  easily distinguishable between markup elements, while JSP needs to enclose
  programming code by <CODE>scriptlet</CODE> tags. The following is an example to show
  the different results based on the same logic and code.</P>
  
<PRE>
&lt;xsp:logic&gt;
 e = request.getParameterNames(); 
 if ((e != null) &amp;amp;&amp;amp; (e.hasMoreElements())) {
  &lt;xsl:content&gt;
   &lt;list&gt;
    &lt;title&gt;Servlet Parameters&lt;/title&gt;
    &lt;xsp:logic&gt;
     while (e.hasMoreElements()) { 
      String k = (String) e.nextElement();
      String val = request.getParameter(k); 
      String vals[] = request.getParameterValues(k);
      &lt;xsp:element name=&quot;element&quot;&gt;
       &lt;xsp:attribute name=&quot;name&quot;&gt;
        &lt;xsp:expr&gt;k&lt;/xsp:expr&gt;
       &lt;/xsp:attribute&gt;
       &lt;xsp:logic&gt;
        for(int i = 0; i &amp;lt; vals.length; i++) {
         &lt;item&gt;
          &lt;xsp:expr&gt;vals[i]&lt;/xsp:expr&gt;
         &lt;/item&gt;
        }
       &lt;/xsp:logic&gt;
      &lt;/xsp:element&gt;
     }
    &lt;/xsp:logic&gt;
   &lt;/list&gt;
  &lt;/xsl:content&gt;
 } 
&lt;/xsp:logic&gt;  
</PRE>

  <P>This is the JSP equivalent:</P>
  
<PRE>
&lt;jsp:scriplet&gt;
 e = request.getParameterNames(); 
 if ((e != null) &amp;amp;&amp;amp; (e.hasMoreElements())) {
&lt;/jsp:scriplet&gt;
  &lt;list&gt;
   &lt;title&gt;Servlet Parameters&lt;/title&gt;
   &lt;jsp:scriplet&gt;
     while (e.hasMoreElements()) { 
      String k = (String) e.nextElement();
      String val = request.getParameter(k); 
      String vals[] = request.getParameterValues(k);
      out.println(&quot;&amp;lt;element name=\&quot;name\&quot;&amp;gt;&quot;);
   &lt;/jsp:scriplet&gt;
      &lt;jsp:expression&gt;k&lt;/jsp:expression&gt;
      &lt;jsp:scriplet&gt;
       out.println(&quot;&amp;lt;/element&amp;gt;&quot;);
       for(int i = 0; i &amp;lt; vals.length; i++) {
      &lt;/jsp:scriplet&gt;
        &lt;item&gt;
         &lt;jsp:expression&gt;vals[i]&lt;/jsp:expression&gt;
        &lt;/item&gt;
      &lt;jsp:scriplet&gt;}&lt;/jsp:scriplet&gt;
    &lt;jsp:scriplet&gt;}&lt;/jsp:scriplet&gt;
  &lt;/list&gt;
&lt;jsp:scriplet&gt;}&lt;/jsp:scriplet&gt;  
</PRE>

  <P>It must be noted the use of the <CODE>out</CODE> object in the JSP example while
  XSP provide specific tags to avoid that.</P>
</DIV>
</DIV>
</BODY>



<H1>Normative References</H1><DIV id="s1">
<UL class="biblio">
  <LI class="biblio"><B>[<A href="http://www.w3.org/TR/REC-DOM-Level-1">DOM</A>]</B> &quot;Document Object Model (DOM) Level 1 Specification&quot;, Lauren Wood et al., 1 October 1998</LI>
      
  <LI class="biblio"><B>[<A href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</A>]</B> &quot;Key words for use in RFCs to Indicate Requirement Levels&quot;, S. Bradner, March 1997</LI>
      
  <LI class="biblio"><B>[<A href="http://www.ietf.org/rfc/rfc2376.txt">RFC2376</A>]</B> &quot;XML Media Types&quot;, E. Whitehead, M. Murata, July 1998</LI>
      
  <LI class="biblio"><B>[<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC2396</A>]</B> &quot;Uniform Resource Identifiers (URI): Generic Syntax&quot;, T. Berners-Lee, R. Fielding, L. Masinter, August 1998</LI>
      
  <LI class="biblio"><B>[<A href="http://www.w3.org/TR/REC-xml">XML</A>]</B> &quot;Extensible Markup Language (XML) 1.0 Specification&quot;, T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998</LI>
      
  <LI class="biblio"><B>[<A href="http://www.w3.org/TR/REC-xml-names">XMLNAMES</A>]</B> &quot;Namespaces in XML&quot;, T. Bray, D. Hollander, A. Layman, 14 January 1999</LI>
      
  <LI class="biblio"><B>[<A href="http://www.w3.org/TR/xslt">XSLT</A>]</B> &quot;XSL Transformations (XSLT) Specification Version 1.0&quot;, J. Clark, 16 November 1999</LI>
      
  <LI class="biblio"><B>[<A href="http://www.megginson.com/SAX/">SAX</A>]</B> &quot;The Simple API for XML (Java implementation) version 1.0&quot;, D.Megginson</LI>
</UL>
</DIV>

</SPECIFICATION><P class="legal">Copyright &copy; 1999-2000 The Apache Software Foundation.<BR>All rights reserved.</P></BODY></HTML>