spacer
Home Events News Links People Catalog Admin
spacer
activepages
spacer
other active pages

Questions or
comments:
webmaster


Updated:
2003-06-13

XML Primer

Jump to the XQuery Section.

Here are two sets of examples to use as you supplement your XML book chapter readings. I have added comments to the examples so please take a look below to supplement your reading.

Lecture example of an XML document (using a DTD)

First, take a look at an example of an XML document for a ficticious (yet quite realistic) Lightning Strike Markup Language (LSML). Our LSML would be used to format information about all lightning strikes that occur within the geographical confines of North America. There is an existing system that delivers real-time lightning strike data called the Internet Data Distribution system. Various science organizations have already deployed lightning strike detectors with wide coverage. These detectors can record time, location, and intensity information on each strike. Lightning strike data is just one of six prime examples of data delivery that could benefit from XML-encoding produced by the Atmospheric Sciences component of the Internet Data Distribution project (click and see the fifth example down). Lightning strikes are batched every twelve minutes and shipped to science teams around the continent. What if they used XML to validate their data?

It is easy to validate an XML document before you ship it off for others to use. This provides a certain confidence to those who process the data. The more uses for the data, the more the XML format is of value. Currently, there are two popular ways to validate XML: Document Type Definition (DTD) schemas and XML Schema schemas. The first lightning strike XML document example here uses a DTD to validate the XML (validation is VERY STRICT, meaning the receiving application should not accept the document if it doesn't validate 100%). In fact, as I created the example, Internet Explorer 6 would not accept my XML document until I cleared up the validation problems (mainly typographical errors I made). Pppular Web sites to validate your XML are provided below each validator example below.

So, why encode lightning strike data using XML? Well, application developers have already built XML toolkits to help you get data out of XML documents and XML validation techniques are being standardized (which is why we are looking at them). So, if we encode each lightning strike as an XML document, we can incorporate that data into all sorts of applications easily. The point is we could have chosen ANY standard to start organizing data on this planet. XML is not magic, it just takes advantage of the popularity of all the HTML work that has been done in the browsers (since the use of less than (<) symbols, greater than (>) symbols, tag identifiers, and attributes are already used in Web page processing).

If you still don't completely understand the motivation for the (sometimes) monotonous details that follow in this primer, ask again in class! The motivation is the most important thing I want to convey to you. You can learn the details as you need to know them (I guess you need to know them somewhat for our first exam). Remember, the details are boring because they are optimized for the computer, not us humans. The strict requirements make the technology easier to implement properly -- processing software does not have to handle multiple conditional formats.

OK, now that we are all motivated, take a look at the example XML document and keep reading the notes afterwards:

<?xml version="1.0" standalone="no"?>

<!DOCTYPE lightning_strike 
    PUBLIC "-//IDD//DTD Lightning_Strike//EN" 
        "http://www.oworld.org/498/xml/ls.dtd">

<lightning_strike>
  <date format="MMDDYYYY">04262002</date>
  <time format="HHMMSS">142609</time>
  <location>
     <northing format="UTM">5526437</northing>
     <easting format="UTM">728964</easting>
     <UTM_tile hemisphere="N">9</UTM_tile>
  </location>
  <detail>
     <intensity>6246</intensity>
     <picture filename="04262002_7.jpg"/> 
  </detail>
</lightning_strike>     

First, notice the hierarchical nesting reinforced by choice of indentation (familiar to HTML experts like ourselves). Take a look at all the XML formatting rules Elizabeth writes about in Chapter 1 of the book. Verify that all of them are followed. Challenge them if you think they are wrong. E-mail me or identify the errors in class. Note how we define our own date and time formats because the DTD specification does not define detailed types (PCDATA means `any data a personal computer could create`). Note how simple the organization is with ELEMENTS, TAGS, and ATTRIBUTES. Try making up your own XML language for something simple you know about. If you are a sports fan, try putting together a PSML (Player Statistics Markup Language) document based on XML. You would have a root element named player and you could have nested elements tracking statistics on each plate appearance for that player in a single game. If you are more business focused, think about how you would create an IRML (Inventory Record Markup Language). Note how some ELEMENTS have opening and closing tags while others just close their one lone tag with />. Lastly, note how the XML document is connected to its validating DTD through the use of the !DOCTYPE tag.

Now, consider that DTD which is reproduced for you just below this paragraph. The DTD has no special idenfication tag to let an unknowledgable user know it is a DTD. The DTD is created for computer processing, not so much for us humans to read. We don't want people who use XML document data to have to know about DTDs, just us designers. If we are designing the language or participating in an industry-wide effort to create it, we will want to review the DTD often to see what types of data are appropriate for that XML-based language. The DTD is the enforcer (like Darren McCarty on the Detroit Red Wings perhaps). Note there are only two tag types for DTDs: !ELEMENT and !ATTLIST. The !ELEMENT tag dictates what elements are valid in the XML document (review how all elements in our XML document above are represented in the DTD). The element then tells us some specifics about its use. The lightning_strike element MUST have four elements nested within it: date, time, location, and detail. They MUST be in that order (Gee, how STRICT, eh?). How can we relax such requirements? As you have read in our XML book: We could use a '+' after the word date to suggest we can have more than one (but must have at least one; we could use a '?' after the word time to suggest we can have one or none; we could use a '*' after the word location to mean we could have none, one, or many).

Take a look at the location !ELEMENT. There we can choose between two lists of nesting elements (the '|' symbol means one OR the other), but one of the two lists is required. Now, contrast the !ELEMENT with the !ATTLIST. The !ATTLIST allows a #REQUIRED identifier when an attribute is required. Note how each !ATTLIST is related to only one element. This is a lack of flexibility that XML Schema overcomes with the concept of creating attribute and element groups. So, now, compare the example here with the example in the book. Ask questions before the exam if you need clarification. Consider the real world example of a DTD which is the last example in this primer. See if you can understand everything the DTD is declaring.

Lecture example of an Document Type Definition (DTD):

<!ELEMENT lightning_strike (date,time,location,detail)>

<!ELEMENT date (#PCDATA)>
<!ATTLIST date format CDATA #REQUIRED>

<!ELEMENT time (#PCDATA)>
<!ATTLIST time format CDATA #REQUIRED>

<!ELEMENT location ((northing, easting, UTM_tile?) | (latitude, longitude))>

<!ELEMENT northing (#PCDATA)>
<!ATTLIST northing format (UTM | latlong) #REQUIRED>

<!ELEMENT easting (#PCDATA)>
<!ATTLIST easting format (UTM | latlong) #REQUIRED>

<!ELEMENT UTM_tile (#PCDATA)>
<!ATTLIST UTM_tile hemisphere (N | S) #REQUIRED>

<!ELEMENT latitude (#PCDATA)>

<!ELEMENT longitude (#PCDATA)>

<!ELEMENT detail (intensity, picture*)>

<!ELEMENT intensity (#PCDATA)>

<!ELEMENT picture EMPTY>
<!ATTLIST picture filename CDATA #REQUIRED>

  • We can validate the document against its DTD using Brown University's XML Validator

    To make XHTML with DTD validation:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE html 
         PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    

    If you prefer to validate your XML with XML Schema (the W3C specification that Microsoft is following closely and blessing in their browser -- IE implements DTD as well of course), you need to write your lightning strike XML document a little differently. Look at the example below and note the differences. Since XML Schema defines native types, we can use the built-in date and time types in our XML document. Note how we connect to both the XML Schema 1.0 specification XML Schema document and our own XML Schema document for our lightning strike markup language validation. You can actually open up the W3C XML Schema document and take a look. The XML Schema for the lightning strike language is further below. You'll want to understand how it works in relation to the XML document here (so continue reading after you've studied the differences in the XML for the XML Schema and DTD validation approaches).

    Lecture example of an XML document (using XML Schema)

    <?xml version="1.0" standalone="no"?>
    
    <lightning_strike xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace= "http://www.oworld.org/498/xml/ls.xsd">
    
      <date>2002-04-26</date>
      <time>14:26:09.445</time>
      <location>
         <northing format="UTM">5526437</northing>
         <easting format="UTM">728964</easting>
         <UTM_tile hemisphere="N">9</UTM_tile>
      </location>
      <detail>
         <intensity>6246</intensity>
         <picture filename="04262002_7.jpg"/> 
      </detail>
    </lightning_strike>     
    

    So, it seems to me XML Schema is better thought out as an implementation. The best news is you can use the same XML parsing logic (algorithms) to read through the XML Schema document as you do for the XML document itself. The big difference is all XML Schema elements have xsd: prefixed to their names. Please note how the XML Schema syntax rules are the same as XML syntax rules. This should simplify things, right? We've already seen how the DTD syntax looks quite different. XML Schema is just as tedious and repetitive though because we have all kinds of extra XML Schema elements to specify our declarations (xsd:complexType, xsd:sequence, xsd:choice, xsd:element, etc.).

    Try and learn the differences between DTD and XML Schema based on each feature you want to write into your validator. For example, note how XML Schema uses minOccurs and maxOccurs attributes to do what DTD did using +, ?, and + characters. Verify you understand why you would want to use the xsd:group element (the reason is to be able to use an element or attribute list multiple places in the same XML Schema declaration). Elizabeth does a good job of explaining the group function in our XML book. DTDs have no such grouping feature. Please find errors in my XML Schema document here so I can fix them if necessary. Creating the XML Schema for the lightning strike XML document was a tedious exercise but Internet Explorer accepted the XML document using the XML Schema validation. So, the following example should be pretty close to the best it could be.

    Example XML Schema

    <?xml version="1.0"?>
    
    <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    
      <xsd:group name="UTM_coords">
        <xsd:sequence>
          <xsd:element name="northing" type="xsd:integer">
             <xsd:complexType>
             <xsd:complexContent>
             <xsd:attribute name="format" type="xsd:string" use="required"/>
             </xsd:complexContent>
             </xsd:complexType>
          </xsd:element>   
          <xsd:element name="easting" type="xsd:integer">
             <xsd:complexType>
             <xsd:complexContent>
             <xsd:attribute name="format" type="xsd:string" use="required"/>
             </xsd:complexContent>
             </xsd:complexType>
          </xsd:element>   
          <xsd:element name="UTM_tile" minOccurs="0" maxOccurs="1">
             <xsd:complexType>
             <xsd:complexContent>
             <xsd:attribute name="hemisphere" type="xsd:string" use="required"/>
             </xsd:complexContent>
             </xsd:complexType>
          </xsd:element>   
        </xsd:sequence>
      </xsd:group>
    
      <xsd:element name="lightning_strike" type="endType">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="date" type="xsd:date" 
                     minOccurs="1" maxOccurs="1"/>
            <xsd:element name="time" type="xsd:time"/>
            <xsd:complexType name="location">
              <xsd:choice>
                <xsd:group ref="UTM_coords"/>
              </xsd:choice>
              <xsd:choice>
                <!-- Another choice like latlong group here -->
              </xsd:choice>
            </xsd:complexType>
            <xsd:complexType name="detail" >
              <xsd:element name="intensity" type="xsd:integer"/>
              <xsd:complexType name="picture">
                <xsd:attribute name="filename"type="xsd:uri" use="required"/> 
              </xsd:complexType> 
            </xsd:complexType>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>     
    

  • The XML document above was validated against this XML Schema at the W3C XML Schema Validator via the copy of the lightning strike XML document on the Web at http://www.oworld.org/498/xml/ls.xml. The validator replied with:

    Schema validating with XSV 2.10-1 of 2005/04/22 13:10:49

    Target: http://www.oworld.org/498/xml/ls.xml
    (Real name: http://www.oworld.org/498/xml/ls.xml
    Length: 509 bytes
    Last Modified: Sat, 15 Apr 2006 11:43:51 GMT
    Server: Apache/2.0.52 (Fedora))
  • docElt: {None}lightning_strike
  • No declaration for document root found, validation was lax
  • The schema(s) used for schema-validation had no errors
  • No schema-validity problems were found in the target

    upon submission of the http://www.oworld.org/498/xml/ls.xml URL in the available form.

    The following example of an XML document with its validating DTD comes straight from our Web server. The XML document specifies initiation information to the Web server whenever the Web server process is started (like a .INI file works in Windows 98). Note that the apache Web server product uses XML for storing data similar to .INI files. The point is to use XML whenever it makes sense to do so. If it ever embeds itself everywhere data is shared on the Web, we'll all be able to write applications that use the data easier (even better when we have multiple applications that want to use the same data. That's the bottom line even though we know some human political tendencies will get in the way of progress at times.

    Also remember, you can get more information than you might ever want about XML Schema from the W3C's XML Schema Reference.

    Real World Example of an XML document:

    <!DOCTYPE web-app 
        PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" 
            "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
    
    <web-app>
     
     <!-- ================================================== -->
     <!-- General options -->
     
     <context-param>
      <param-name>propfile</param-name>
      <param-value>/WEB-INF/NeatSeeker.properties</param-value>
      <description>
       Path to the NeatSeeker properties file (relative to
       the context root).
      </description>
     </context-param>
    
     <!-- ================================================== -->
     <!-- Servlet definitions -->
    
     <servlet>
      <servlet-name>dts</servlet-name>
      <servlet-class>dods.servers.test.dts</servlet-class>
      <init-param>
        <param-name>iniFilePath</param-name>
        <param-value>/usr/dods/dts</param-value>
      </init-param>
      <init-param>
        <param-name>iniFileName</param-name>
        <param-value>dts.ini</param-value>
      </init-param>
     </servlet>
     <servlet>
      <servlet-name>Seeker</servlet-name>
      <servlet-class>lempinen.neatseeker.servlet.Seeker</servlet-class>
     </servlet>
    
     <!-- ================================================== -->
     <!-- Servlet mapping -->
    
     <servlet-mapping>
      <servlet-name>Seeker</servlet-name>
      <url-pattern>/Seeker</url-pattern>
     </servlet-mapping>
     
     <!-- ================================================== -->
     <!-- Session configuration -->
     <session-config>
      <session-timeout>30</session-timeout>    <!-- 30 minutes -->
     </session-config>
    
    </web-app>
    

    XQuery

    What is XQuery?

    • XQuery is the language for querying XML data
    • XQuery for XML is like SQL for databases
    • XQuery is built on XPath expressions
    • XQuery is defined by the W3C
    • XQuery is supported by all the major database engines (IBM, Oracle, Microsoft, etc.)
    • XQuery will become a W3C standard (currently a Working Draft), and developers can be sure that the code will work among different products

    XQuery 1.0 and XPath 2.0 share the same data model and support the same functions and operators. As you have already studied XPath in the XML book, you should have no problems with understanding XQuery.


    XQuery can be used to:

    • Extract information to use in a Web Service
    • Generate summary reports
    • Transform XML data to XHTML
    • Search Web documents for relevant information

    Basic Online XQuery Reference
    XQuery Examples
    The ExistDB Home Page

    Examples from class: let $x:= //units return $x let $x:= //location return $x for $x in //data/location/values[oceantemp>17.0] return $x/oceantemp let $x := max(//data/location/values/oceantemp) return $x let $x := count(//data/location/values[airtemp=9999.0]/airtemp) return $x let $x := avg(//data/location/values[oceantemp>2.0]/oceantemp) return $x for $x in //data/location[values/oceantemp>17.0] return $x/(x | y) for $x in //data[location/values/oceantemp>17.0] return $x/time let $x:= //location[landnorth>0] return $x let $x := max(//data/location/values/oceantemp) return if ($x > 10) then "yes" else "no" for $x in //data/location/values/riverflow where some $r in $x satisfies $r < 2000.0 and $r > 1900.0 return $x

    Example Data Document: <data> <date>04-09-2006</date> <time>4</time> <location> <x>7</x> <y>51</y> <values> <precip>9.47706221914e-010</precip> <airtemp>190.806568846</airtemp> <wind>-0.69160763042</wind> <winddir>9999.0</winddir> <soiltemp>0.0</soiltemp> <soilmoist>0.0</soilmoist> <watertable>0.0</watertable> <snowwater>0.0</snowwater> <oceantemp>0.0</oceantemp> <currentu>0.0</currentu> <currentv>0.0</currentv> <salinity>0.0</salinity> <zoo>0.0</zoo> <phyto>0.0</phyto> <no3>0.0</no3> <o2>0.0</o2> <po4>0.0</po4> <riverflow>9999.9</riverflow> </values> </location> </data>

    The Units Document: <units> <precip abbr ="mm">millimeters</precip> <airtemp abbr ="K">degrees Kelvin</airtemp> <humidity abbr ="%">percent</humidity> <wind abbr ="m/s">meters per second</wind> <winddir abbr ="NWSE">compass heading</winddir> <shortwave abbr ="W/m^2">watts/meters-squared</shortwave> <longwave abbr ="W/m^2">watts/meters-squared</longwave> <soiltemp abbr ="C">degrees Celsius</soiltemp> <soilmoist abbr ="%">percent</soilmoist> <watertable abbr ="m">meters</watertable> <snowwater abbr ="m^3">meters-cubed</snowwater> <porosity abbr ="%">percent</porosity> <grainsize abbr ="m">millimeters</grainsize> <oceantemp abbr ="C">degrees Celsius</oceantemp> <currentu abbr ="m/sec">x meters per second</currentu> <currentv abbr ="m/sec">y meters per second</currentv> <salinity abbr ="ppt">parts per thousand</salinity> <zoo abbr ="mmo">mmo</zoo> <phyto abbr ="mmo">mmo</phyto> <no3 abbr ="mmo">mmo</no3> <o2 abbr ="mmo">mmo</o2> <po4 abbr ="mmo">mmo</po4> <light abbr ="ph/sec*m^3">photons/second*meters-cubed</light> <riverflow abbr ="ft^3/sec">feet-cubed per second</riverflow> <rivervolume abbr ="m^3">meters-cubed</rivervolume> <rivertemp abbr ="C">degrees Celsius</rivertemp> </units>

    The World Coordinates Document : <location> <landnorth type ="UTM">5325350</landnorth> <landwest type ="UTM">564050</landwest> <landlongitude type ="center">-121.5828168315</landlongitude> <landlatitude type ="center">47.70478600794</landlatitude> <landspacing type ="meters">1500</landspacing> <waternorth type ="UTM">5424030</waternorth> <waterwest type ="UTM">487140</waterwest> <waterlongitude type ="west">-123.5000</waterlongitude> <waterlatitude type ="north">49.0000</waterlatitude> <waterxspacing type ="meters">360</waterxspacing> <wateryspacing type ="meters">540</wateryspacing> </location>

    Real World Example of a DTD:

    <!--
    Copyright 1999 Sun Microsystems, Inc. 901 San Antonio Road,
    Palo Alto, CA  94303, U.S.A.  All rights reserved.
     
    This product or document is protected by copyright and distributed
    under licenses restricting its use, copying, distribution, and
    decompilation.  No part of this product or documentation may be
    reproduced in any form by any means without prior written authorization
    of Sun and its licensors, if any.  
    
    Third party software, including font technology, is copyrighted and 
    licensed from Sun suppliers. 
    
    Sun, Sun Microsystems, the Sun Logo, Solaris, Java, JavaServer Pages, Java 
    Naming and Directory Interface, JDBC, JDK, JavaMail and Enterprise JavaBeans, 
    are trademarks or registered trademarks of Sun Microsystems, Inc in the U.S. 
    and other countries.
    
    All SPARC trademarks are used under license and are trademarks
    or registered trademarks of SPARC International, Inc.
    in the U.S. and other countries. Products bearing SPARC
    trademarks are based upon an architecture developed by Sun Microsystems, Inc. 
    
    PostScript is a registered trademark of Adobe Systems, Inc. 
    
    Federal Acquisitions: Commercial Software - Government Users Subject to 
    Standard License Terms and Conditions.
    
    DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED
    CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY
    IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
    PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT
    TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
    INVALID.
    
    _________________________________________________________________________
    Copyright 1999 Sun Microsystems, Inc., 
    901 San Antonio Road, Palo Alto, CA  94303, Etats-Unis. 
    Tous droits re'serve's.
     
    
    Ce produit ou document est prote'ge' par un copyright et distribue' avec 
    des licences qui en restreignent l'utilisation, la copie, la distribution,
    et la de'compilation.  Aucune partie de ce produit ou de sa documentation
    associe'e ne peut e^tre reproduite sous aucune forme, par quelque moyen 
    que ce soit, sans l'autorisation pre'alable et e'crite de Sun et de ses 
    bailleurs de licence, s'il y en a.  
    
    Le logiciel de'tenu par des tiers, et qui comprend la technologie 
    relative aux polices de caracte`res, est prote'ge' par un copyright 
    et licencie' par des fournisseurs de Sun.
     
    Sun, Sun Microsystems, le logo Sun, Solaris, Java, JavaServer Pages, Java 
    Naming and Directory Interface, JDBC, JDK, JavaMail, et Enterprise JavaBeans,  
    sont des marques de fabrique ou des marques de'pose'es de Sun 
    Microsystems, Inc. aux Etats-Unis et dans d'autres pays.
     
    Toutes les marques SPARC sont utilise'es sous licence et sont
    des marques de fabrique ou des marques de'pose'es de SPARC
    International, Inc. aux Etats-Unis et  dans
    d'autres pays. Les produits portant les marques SPARC sont
    base's sur une architecture de'veloppe'e par Sun Microsystems, Inc.  
    
    Postcript est une marque enregistre'e d'Adobe Systems Inc. 
     
    LA DOCUMENTATION EST FOURNIE "EN L'ETAT" ET TOUTES AUTRES CONDITIONS,
    DECLARATIONS ET GARANTIES EXPRESSES OU TACITES SONT FORMELLEMENT EXCLUES,
    DANS LA MESURE AUTORISEE PAR LA LOI APPLICABLE, Y COMPRIS NOTAMMENT
    TOUTE GARANTIE IMPLICITE RELATIVE A LA QUALITE MARCHANDE, A L'APTITUDE
    A UNE UTILISATION PARTICULIERE OU A L'ABSENCE DE CONTREFACON.
    -->
    
    <!--
    The web-app element is the root of the deployment descriptor for
    a web application
    -->
    
    <!ELEMENT web-app (icon?, display-name?, description?, distributable?,
    context-param*, servlet*, servlet-mapping*, session-config?,
    mime-mapping*, welcome-file-list?, error-page*, taglib*,
    resource-ref*, security-constraint*, login-config?, security-role*,
    env-entry*, ejb-ref*)>
    
    <!--
    The icon element contains a small-icon and a large-icon element
    which specify the location within the web application for a small and
    large image used to represent the web application in a GUI tool. At a
    minimum, tools must accept GIF and JPEG format images.
    -->
    
    <!ELEMENT icon (small-icon?, large-icon?)>
    
    <!--
    The small-icon element contains the location within the web
    application of a file containing a small (16x16 pixel) icon image.
    -->
    
    <!ELEMENT small-icon (#PCDATA)>
    
    <!--
    The large-icon element contains the location within the web
    application of a file containing a large (32x32 pixel) icon image.
    -->
    
    <!ELEMENT large-icon (#PCDATA)>
    
    <!--
    The display-name element contains a short name that is intended
    to be displayed by GUI tools
    -->
    
    <!ELEMENT display-name (#PCDATA)>
    
    <!--
    The description element is used to provide descriptive text about
    the parent element.
    -->
    
    <!ELEMENT description (#PCDATA)>
    
    <!--
    The distributable element, by its presence in a web application
    deployment descriptor, indicates that this web application is
    programmed appropriately to be deployed into a distributed servlet
    container
    -->
    
    <!ELEMENT distributable EMPTY>
    
    <!--
    The context-param element contains the declaration of a web
    application's servlet context initialization parameters.
    -->
    
    <!ELEMENT context-param (param-name, param-value, description?)>
    
    <!--
    The param-name element contains the name of a parameter.
    -->
    
    <!ELEMENT param-name (#PCDATA)>
    
    <!--
    The param-value element contains the value of a parameter.
    -->
    
    <!ELEMENT param-value (#PCDATA)>
    
    <!--
    The servlet element contains the declarative data of a
    servlet. If a jsp-file is specified and the load-on-startup element is
    present, then the JSP should be precompiled and loaded.
    -->
    
    <!ELEMENT servlet (icon?, servlet-name, display-name?, description?,
    (servlet-class|jsp-file), init-param*, load-on-startup?, security-role-ref*)>
    
    <!--
    The servlet-name element contains the canonical name of the
    servlet.
    -->
    
    <!ELEMENT servlet-name (#PCDATA)>
    
    <!--
    The servlet-class element contains the fully qualified class name
    of the servlet.
    -->
    
    <!ELEMENT servlet-class (#PCDATA)>
    
    <!--
    The jsp-file element contains the full path to a JSP file within
    the web application.
    -->
    
    <!ELEMENT jsp-file (#PCDATA)>
    
    <!--
    The init-param element contains a name/value pair as an
    initialization param of the servlet
    -->
    
    <!ELEMENT init-param (param-name, param-value, description?)>
    
    <!--
    The load-on-startup element indicates that this servlet should be
    loaded on the startup of the web application. The optional contents of
    these element must be a positive integer indicating the order in which
    the servlet should be loaded. Lower integers are loaded before higher
    integers. If no value is specified, or if the value specified is not a
    positive integer, the container is free to load it at any time in the
    startup sequence.
    -->
    
    <!ELEMENT load-on-startup (#PCDATA)>
    
    <!--
    The servlet-mapping element defines a mapping between a servlet
    and a url pattern
    -->
    
    <!ELEMENT servlet-mapping (servlet-name, url-pattern)>
    
    <!--
    The url-pattern element contains the url pattern of the
    mapping. Must follow the rules specified in Section 10 of the Servlet
    API Specification.
    -->
    
    <!ELEMENT url-pattern (#PCDATA)>
    
    <!--
    The session-config element defines the session parameters for
    this web application.
    -->
    
    <!ELEMENT session-config (session-timeout?)>
    
    <!--
    The session-timeout element defines the default session timeout
    interval for all sessions created in this web application. The
    specified timeout must be expressed in a whole number of minutes.
    -->
    
    <!ELEMENT session-timeout (#PCDATA)>
    
    <!--
    The mime-mapping element defines a mapping between an extension
    and a mime type.
    -->
    
    <!ELEMENT mime-mapping (extension, mime-type)>
    
    <!--
    The extension element contains a string describing an
    extension. example: "txt"
    -->
    
    <!ELEMENT extension (#PCDATA)>
    
    <!--
    The mime-type element contains a defined mime type. example:
    "text/plain"
    -->
    
    <!ELEMENT mime-type (#PCDATA)>
    
    <!--
    The welcome-file-list contains an ordered list of welcome files
    elements.
    -->
    
    <!ELEMENT welcome-file-list (welcome-file+)>
    
    <!--
    The welcome-file element contains file name to use as a default
    welcome file, such as index.html
    -->
    
    <!ELEMENT welcome-file (#PCDATA)>
    
    <!--
    The taglib element is used to describe a JSP tag library.
    -->
    
    <!ELEMENT taglib (taglib-uri, taglib-location)>
    
    <!--
    The taglib-uri element describes a URI, relative to the location
    of the web.xml document, identifying a Tag Library used in the Web
    Application.
    -->
    
    <!ELEMENT taglib-uri (#PCDATA)>
    
    <!--
    the taglib-location element contains the location (as a resource
    relative to the root of the web application) where to find the Tag
    Libary Description file for the tag library.
    -->
    
    <!ELEMENT taglib-location (#PCDATA)>
    
    <!--
    The error-page element contains a mapping between an error code
    or exception type to the path of a resource in the web application
    -->
    
    <!ELEMENT error-page ((error-code | exception-type), location)>
    
    <!--
    The error-code contains an HTTP error code, ex: 404
    -->
    
    <!ELEMENT error-code (#PCDATA)>
    
    <!--
    The exception type contains a fully qualified class name of a
    Java exception type.
    -->
    
    <!ELEMENT exception-type (#PCDATA)>
    
    <!--
    The location element contains the location of the resource in the
    web application
    -->
    
    <!ELEMENT location (#PCDATA)>
    
    <!--
    The resource-ref element contains a declaration of a Web
    Application's reference to an external resource.
    -->
    
    <!ELEMENT resource-ref (description?, res-ref-name, res-type, res-auth)>
    
    <!--
    The res-ref-name element specifies the name of the resource
    factory reference name.
    -->
    
    <!ELEMENT res-ref-name (#PCDATA)>
    
    <!--
    The res-type element specifies the (Java class) type of the data
    source.
    -->
    
    <!ELEMENT res-type (#PCDATA)>
    
    <!--
    The res-auth element indicates whether the application component
    code performs resource signon programmatically or whether the
    container signs onto the resource based on the principle mapping
    information supplied by the deployer. Must be CONTAINER or SERVLET
    -->
    
    <!ELEMENT res-auth (#PCDATA)>
    
    <!--
    The security-constraint element is used to associate security
    constraints with one or more web resource collections
    -->
    
    <!ELEMENT security-constraint (web-resource-collection+,
    auth-constraint?, user-data-constraint?)>
    
    <!--
    The web-resource-collection element is used to identify a subset
    of the resources and HTTP methods on those resources within a web
    application to which a security constraint applies. If no HTTP methods
    are specified, then the security constraint applies to all HTTP
    methods.
    -->
    
    <!ELEMENT web-resource-collection (web-resource-name, description?,
    url-pattern*, http-method*)>
    
    <!--
    The web-resource-name contains the name of this web resource
    collection
    -->
    
    <!ELEMENT web-resource-name (#PCDATA)>
    
    <!--
    The http-method contains an HTTP method (GET | POST |...)
    -->
    
    <!ELEMENT http-method (#PCDATA)>
    
    <!--
    The user-data-constraint element is used to indicate how data
    communicated between the client and container should be protected
    -->
    
    <!ELEMENT user-data-constraint (description?, transport-guarantee)>
    
    <!--
    The transport-guarantee element specifies that the communication
    between client and server should be NONE, INTEGRAL, or
    CONFIDENTIAL. NONE means that the application does not require any
    transport guarantees. A value of INTEGRAL means that the application
    requires that the data sent between the client and server be sent in
    such a way that it can't be changed in transit. CONFIDENTIAL means
    that the application requires that the data be transmitted in a
    fashion that prevents other entities from observing the contents of
    the transmission. In most cases, the presence of the INTEGRAL or
    CONFIDENTIAL flag will indicate that the use of SSL is required.
    -->
    
    <!ELEMENT transport-guarantee (#PCDATA)>
    
    <!--
    The auth-constraint element indicates the user roles that should
    be permitted access to this resource collection. The role used here
    must appear in a security-role-ref element.
    -->
    
    <!ELEMENT auth-constraint (description?, role-name*)>
    
    <!--
    The role-name element contains the name of a security role.
    -->
    
    <!ELEMENT role-name (#PCDATA)>
    
    <!--
    The login-config element is used to configure the authentication
    method that should be used, the realm name that should be used for
    this application, and the attributes that are needed by the form login
    mechanism.
    -->
    
    <!ELEMENT login-config (auth-method?, realm-name?, form-login-config?)>
    
    <!--
    The realm name element specifies the realm name to use in HTTP
    Basic authorization
    -->
    
    <!ELEMENT realm-name (#PCDATA)>
    
    <!--
    The form-login-config element specifies the login and error pages
    that should be used in form based login. If form based authentication
    is not used, these elements are ignored.
    -->
    
    <!ELEMENT form-login-config (form-login-page, form-error-page)>
    
    <!--
    The form-login-page element defines the location in the web app
    where the page that can be used for login can be found
    -->
    
    <!ELEMENT form-login-page (#PCDATA)>
    
    <!--
    The form-error-page element defines the location in the web app
    where the error page that is displayed when login is not successful
    can be found
    -->
    
    <!ELEMENT form-error-page (#PCDATA)>
    
    <!--
    The auth-method element is used to configure the authentication
    mechanism for the web application. As a prerequisite to gaining access
    to any web resources which are protected by an authorization
    constraint, a user must have authenticated using the configured
    mechanism. Legal values for this element are "BASIC", "DIGEST",
    "FORM", or "CLIENT-CERT".
    -->
    
    <!ELEMENT auth-method (#PCDATA)>
    
    <!--
    The security-role element contains the declaration of a security
    role which is used in the security-constraints placed on the web
    application.
    -->
    
    <!ELEMENT security-role (description?, role-name)>
    
    <!--
    The role-name element contains the name of a role. This element
    must contain a non-empty string.
    -->
    
    <!ELEMENT security-role-ref (description?, role-name, role-link)>
    
    <!--
    The role-link element is used to link a security role reference
    to a defined security role. The role-link element must contain the
    name of one of the security roles defined in the security-role
    elements.
    -->
    
    <!ELEMENT role-link (#PCDATA)>
    
    <!--
    The env-entry element contains the declaration of an
    application's environment entry. This element is required to be
    honored on in J2EE compliant servlet containers.
    -->
    
    <!ELEMENT env-entry (description?, env-entry-name, env-entry-value?,
    env-entry-type)>
    
    <!--
    The env-entry-name contains the name of an application's
    environment entry
    -->
    
    <!ELEMENT env-entry-name (#PCDATA)>
    
    <!--
    The env-entry-value element contains the value of an
    application's environment entry
    -->
    
    <!ELEMENT env-entry-value (#PCDATA)>
    
    <!--
    The env-entry-type element contains the fully qualified Java type
    of the environment entry value that is expected by the application
    code. The following are the legal values of env-entry-type:
    java.lang.Boolean, java.lang.String, java.lang.Integer,
    java.lang.Double, java.lang.Float.
    -->
    
    <!ELEMENT env-entry-type (#PCDATA)>
    
    <!--
    The ejb-ref element is used to declare a reference to an
    enterprise bean. 
    -->
    
    <!ELEMENT ejb-ref (description?, ejb-ref-name, ejb-ref-type, home, remote,
    ejb-link?)>
    
    <!--
    The ejb-ref-name element contains the name of an EJB
    reference. This is the JNDI name that the servlet code uses to get a
    reference to the enterprise bean.
    -->
    
    <!ELEMENT ejb-ref-name (#PCDATA)>
    
    <!--
    The ejb-ref-type element contains the expected java class type of
    the referenced EJB.
    -->
    
    <!ELEMENT ejb-ref-type (#PCDATA)>
    
    <!--
    The ejb-home element contains the fully qualified name of the
    EJB's home interface
    -->
    
    <!ELEMENT home (#PCDATA)>
    
    <!--
    The ejb-remote element contains the fully qualified name of the
    EJB's remote interface
    -->
    
    <!ELEMENT remote (#PCDATA)>
    
    <!--
    The ejb-link element is used in the ejb-ref element to specify
    that an EJB reference is linked to an EJB in an encompassing Java2
    Enterprise Edition (J2EE) application package. The value of the
    ejb-link element must be the ejb-name of and EJB in the J2EE
    application package.
    -->
    
    <!ELEMENT ejb-link (#PCDATA)>
    
    <!--
    The ID mechanism is to allow tools to easily make tool-specific
    references to the elements of the deployment descriptor. This allows
    tools that produce additional deployment information (i.e information
    beyond the standard deployment descriptor information) to store the
    non-standard information in a separate file, and easily refer from
    these tools-specific files to the information in the standard web-app
    deployment descriptor.
    -->
    
    <!ATTLIST web-app id ID #IMPLIED>
    <!ATTLIST icon id ID #IMPLIED>
    <!ATTLIST small-icon id ID #IMPLIED>
    <!ATTLIST large-icon id ID #IMPLIED>
    <!ATTLIST display-name id ID #IMPLIED>
    <!ATTLIST description id ID #IMPLIED>
    <!ATTLIST distributable id ID #IMPLIED>
    <!ATTLIST context-param id ID #IMPLIED>
    <!ATTLIST param-name id ID #IMPLIED>
    <!ATTLIST param-value id ID #IMPLIED>
    <!ATTLIST servlet id ID #IMPLIED>
    <!ATTLIST servlet-name id ID #IMPLIED>
    <!ATTLIST servlet-class id ID #IMPLIED>
    <!ATTLIST jsp-file id ID #IMPLIED>
    <!ATTLIST init-param id ID #IMPLIED>
    <!ATTLIST load-on-startup id ID #IMPLIED>
    <!ATTLIST servlet-mapping id ID #IMPLIED>
    <!ATTLIST url-pattern id ID #IMPLIED>
    <!ATTLIST session-config id ID #IMPLIED>
    <!ATTLIST session-timeout id ID #IMPLIED>
    <!ATTLIST mime-mapping id ID #IMPLIED>
    <!ATTLIST extension id ID #IMPLIED>
    <!ATTLIST mime-type id ID #IMPLIED>
    <!ATTLIST welcome-file-list id ID #IMPLIED>
    <!ATTLIST welcome-file id ID #IMPLIED>
    <!ATTLIST taglib id ID #IMPLIED>
    <!ATTLIST taglib-uri id ID #IMPLIED>
    <!ATTLIST taglib-location id ID #IMPLIED>
    <!ATTLIST error-page id ID #IMPLIED>
    <!ATTLIST error-code id ID #IMPLIED>
    <!ATTLIST exception-type id ID #IMPLIED>
    <!ATTLIST location id ID #IMPLIED>
    <!ATTLIST resource-ref id ID #IMPLIED>
    <!ATTLIST res-ref-name id ID #IMPLIED>
    <!ATTLIST res-type id ID #IMPLIED>
    <!ATTLIST res-auth id ID #IMPLIED>
    <!ATTLIST security-constraint id ID #IMPLIED>
    <!ATTLIST web-resource-collection id ID #IMPLIED>
    <!ATTLIST web-resource-name id ID #IMPLIED>
    <!ATTLIST http-method id ID #IMPLIED>
    <!ATTLIST user-data-constraint id ID #IMPLIED>
    <!ATTLIST transport-guarantee id ID #IMPLIED>
    <!ATTLIST auth-constraint id ID #IMPLIED>
    <!ATTLIST role-name id ID #IMPLIED>
    <!ATTLIST login-config id ID #IMPLIED>
    <!ATTLIST realm-name id ID #IMPLIED>
    <!ATTLIST form-login-config id ID #IMPLIED>
    <!ATTLIST form-login-page id ID #IMPLIED>
    <!ATTLIST form-error-page id ID #IMPLIED>
    <!ATTLIST auth-method id ID #IMPLIED>
    <!ATTLIST security-role id ID #IMPLIED>
    <!ATTLIST security-role-ref id ID #IMPLIED>
    <!ATTLIST role-link id ID #IMPLIED>
    <!ATTLIST env-entry id ID #IMPLIED>
    <!ATTLIST env-entry-name id ID #IMPLIED>
    <!ATTLIST env-entry-value id ID #IMPLIED>
    <!ATTLIST env-entry-type id ID #IMPLIED>
    <!ATTLIST ejb-ref id ID #IMPLIED>
    <!ATTLIST ejb-ref-name id ID #IMPLIED>
    <!ATTLIST ejb-ref-type id ID #IMPLIED>
    <!ATTLIST home id ID #IMPLIED>
    <!ATTLIST remote id ID #IMPLIED>
    <!ATTLIST ejb-link id ID #IMPLIED>