 |
|
|||||
|
||||||
|
|
|||
|
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>
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>
Schema validating with XSV 2.10-1 of 2005/04/22 13:10:49
Target: http://www.oworld.org/498/xml/ls.xml 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>
XQueryWhat is XQuery?
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:
Basic Online XQuery Reference
|
|||
