1_xml.html

XML_JAVA指南 书籍语言： 简体中文 书籍类型： 程序设计 授权方式： 免费软件 书籍大小： 377 KB

    information on these and many other aspects of XML, see the Recommended Reading 
    list of the w3c XML page at <a href="http://www.w3.org/XML/"><code>http://www.w3.org/XML/</code></a>.</p>
  <blockquote> 
    <p><b>Note: </b>The declaration is actually optional. But it's a good idea 
      to include it whenever you create an XML file. The declaration should have 
      the version number, at a minimum, and ideally the encoding as well. That 
      standard simplifies things if the XML standard is extended in the future, 
      and if the data ever needs to be localized for different geographical regions.</p>
  </blockquote>
</blockquote>
<h4><a name="processingInstructions"></a>Processing Instructions</h4>
<blockquote> 
  <p>An XML file can also contain <i>processing instructions</i> that give commands 
    or information to an application that is processing the XML data. Processing 
    instructions have the following format:</p>
  <pre>  &lt;?<i>target</i> <i>instructions</i>?&gt;</pre>
  <p>where the <i>target</i> is the name of the application that is expected to 
    do the processing, and <i>instructions</i> is a string of characters that 
    embodies the information or commands for the application to process.</p>
  <p>Since the instructions are application specific, an XML file could have multiple 
    processing instructions that tell different applications to do similar things, 
    though in different ways. The XML file for a slideshow, for example, could 
    have processing instructions that let the speaker specify a technical or executive-level 
    version of the presentation. If multiple presentation programs were used, 
    the program might need multiple versions of the processing instructions (although 
    it would be nicer if such applications recognized standard instructions).</p>
  <blockquote> 
    <p><b>Note: </b>The target name &quot;xml&quot; (in any combination of upper 
      or lowercase letters) is reserved for XML standards. In one sense, the declaration 
      is a processing instruction that fits that standard. (However, when you're 
      working with the parser later, you'll see that the method for handling processing 
      instructions never sees the declaration.)</p>
  </blockquote>
</blockquote>
<h3><a name="cool"></a>Why Is XML Important?</h3>
<blockquote> 
  <p> There are a number of reasons for XML's surging acceptance. This section 
    lists a few of the most prominent.</p>
  <h4>Plain Text</h4>
  <p>Since XML is not a binary format, you can create and edit files with anything 
    from a standard text editor to a visual development environment. That makes 
    it easy to debug your programs, and makes it useful for storing small amounts 
    of data. At the other end of the spectrum, an XML front end to a database 
    makes it possible to efficiently store large amounts of XML data as well. 
    So XML provides scalability for anything from small configuration files to 
    a company-wide data repository.</p>
  <h4>Data Identification</h4>
  <p>XML tells you what kind of data you have, not how to display it. Because 
    the markup tags identify the information and break up the data into parts, 
    an email program can process it, a search program can look for messages sent 
    to particular people, and an address book can extract the address information 
    from the rest of the message. In short, because the different parts of the 
    information have been identified, they can be used in different ways by different 
    applications.</p>
  <h4><a name="stylability"></a>Stylability</h4>
  <p> When display is important, the stylesheet standard, <a href="2_specs.html#XSL">XSL</a>, 
    lets you dictate how to portray the data. For example, the stylesheet for:</p>
  <pre>&lt;to&gt;[e-mail]&lt;/to&gt;</pre>
  <p>can say:</p>
  <ol>
    <li>Start a new line.</li>
    <li>Display &quot;To:&quot; in bold, followed by a space</li>
    <li>Display the destination data.</li>
  </ol>
  <p>Which produces:</p>
  <pre><b>To: </b>you@yourAddress</pre>
  <p>Of course, you could have done the same thing in HTML, but you wouldn't be 
    able to process the data with search programs and address-extraction programs 
    and the like. More importantly, since XML is inherently style-free, you can 
    use a completely different stylesheet to produce output in postscript, TEX, 
    PDF, or some new format that hasn't even been invented yet. That flexibility 
    amounts to what one author described as &quot;future-proofing&quot; your information. 
    The XML documents you author today can be used in future document-delivery 
    systems that haven't even been imagined yet.</p>
  <h4><a name="inline"></a>Inline Reusabiliy</h4>
  <p>One of the nicer aspects of XML documents is that they can be composed from 
    separate entities. You can do that with HTML, but only by linking to other 
    documents. Unlike HTML, XML entities can be included &quot;in line&quot; in 
    a document. The included sections look like a normal part of the document 
    -- you can search the whole document at one time or download it in one piece. 
    That lets you modularize your documents without resorting to links. You can 
    single-source a section so that an edit to it is reflected everywhere the 
    section is used, and yet a document composed from such pieces looks for all 
    the world like a one-piece document. </p>
  <h4><a name="linking"></a>Linkability</h4>
  <p>Thanks to HTML, the ability to define links between documents is now regarded 
    as a necessity. The next section of this tutorial, <a href="2_specs.html">XML 
    and Related Specs</a>, discusses the link-specification initiative. This initiative 
    lets you define two-way links, multiple-target links, &quot;expanding&quot; 
    links (where clicking a link causes the targeted information to appear inline), 
    and links between two existing documents that are defined in a third.<index key="wellFormed"> 
  </p>
  <h4>Easily Processed</h4>
  <p>As mentioned earlier, regular and consistent notation makes it easier to 
    build a program to process XML data. For example, in HTML a <code>&lt;dt&gt;</code> 
    tag can be delimited by <code>&lt;/dt&gt;</code>, another <code>&lt;dt&gt;</code>, 
    <code>&lt;dd&gt;</code>, or <code>&lt;/dl&gt;</code>. That makes for some 
    difficult programming. But in XML, the <code>&lt;dt&gt;</code> tag must always 
    have a <code>&lt;/dt&gt;</code> terminator, or else it will be defined as 
    a <code>&lt;dt/&gt;</code> tag. That restriction is a critical part of the 
    constraints that make an XML document <a href="../glossary.html#wellFormed">well-formed</a>. 
    (Otherwise, the XML parser won't be able to read the data.) And since XML 
    is a vendor-neutral standard, you can choose among several XML parsers, any 
    one of which takes the work out of processing XML data.</p>
  <h4>Hierarchical</h4>
  <p>Finally, XML documents benefit from their hierarchical structure. Hierarchical 
    document structures are, in general, faster to access because you can drill 
    down to the part you need, like stepping through a table of contents. They 
    are also easier to rearrange, because each piece is delimited. In a document, 
    for example, you could move a heading to a new location and drag everything 
    under it along with the heading, instead of having to page down to make a 
    selection, cut, and then paste the selection into a new location.</p>
</blockquote>
<h3><a name="uses"></a>How Can You Use XML?</h3>
<blockquote> 
  <p>There are several basic ways to make use of XML:</p>
  <ul>
    <li>Traditional data processing, where XML encodes the data for a program 
      to process</li>
    <p> 
    <li>Document-driven programming, where XML documents are containers that build 
      interfaces and applications from existing components</li>
    <p> 
    <li>Archiving -- the foundation for document-driven programming, where the 
      customized version of a component is saved (archived) so it can be used 
      later</li>
    <p> 
    <li>Binding, where the DTD or schema that defines an XML data structure is 
      used to automatically generate a significant portion of the application 
      that will eventually process that data</li>
  </ul>
  <h4><a name="DP"></a>Traditional Data Processing</h4>
  <p>XML is fast becoming the data representation of choice for the Web. It's 
    terrific when used in conjunction with network-centric Java-platform programs 
    that send and retrieve information. So a client/server application, for example, 
    could transmit XML-encoded data back and forth between the client and the 
    server. </p>
  <p>In the future, XML is potentially the answer for data interchange in all 
    sorts of transactions, as long as both sides agree on the markup to use. (For 
    example, should an email program expect to see tags named <code>&lt;FIRST&gt;</code> 
    and <code>&lt;LAST&gt;</code>, or <code>&lt;FIRSTNAME&gt;</code> and <code>&lt;LASTNAME&gt;</code>?) 
    The need for common standards will generate a lot of industry-specific standardization 
    efforts in the years ahead. In the meantime, mechanisms that let you &quot;translate&quot; 
    the tags in an XML document will be important. Such mechanisms include projects 
    like the <a href="2_specs.html#RDF">RDF</a> initiative, which defines &quot;meta 
    tags&quot;, and the <a href="2_specs.html#XSL">XSL</a> specification, which 
    lets you translate XML tags into other XML tags. </p>
  <h4><a name="DDP"></a>Document-Driven Programming (DDP)</h4>
  <p>The newest approach to using XML is to construct a document that describes 
    how an application page should look. The document, rather than simply being 
    displayed, consists of references to user interface components and business-logic 
    components that are &quot;hooked together&quot; to create an application on 
    the fly.</p>
  <p>Of course, it makes sense to utilize the Java platform for such components. 
    Both Java Beans<sup><font size="1">TM</font></sup> for interfaces and Enterprise 
    Java Beans<sup><font size="1">TM</font></sup> for business logic can be used 
    to construct such applications. Although none of the efforts undertaken so 
    far are ready for commercial use, much preliminary work has already been done.</p>
  <blockquote> 
    <p><b>Note: </b>The Java programming language is also excellent for writing 
      XML-processing tools that are as portable as XML. Several Visual XML editors 
      have been written for the Java platform. For a listing of editors, processing 
      tools, and other XML resources, see the &quot;Software&quot; section of 
      Robin Cover's <a href="http://www.oasis-open.org/cover/"> SGML/XML Web Page</a>. 
    </p>
  </blockquote>
  <h4><a name="binding"></a>Binding</h4>
  <p>Once you have defined the structure of XML data using either a DTD or the 
    one of the schema standards, a large part of the processing you need to do 
    has already been defined. For example, if the schema says that the text data 
    in a <code>&lt;date&gt;</code> element must follow one of the recognized date 
    formats, then one aspect of the validation criteria for the data has been 
    defined -- it only remains to write the code. Although a DTD specification 
    cannot go the same level of detail, a DTD (like a schema) provides a grammar 
    that tells which data structures can occur, in what sequences. That specification 
    tells you how to write the high-level code that processes the data elements.</p>
  <p>But when the data structure (and possibly format) is fully specified, the 
    code you need to process it can just as easily be generated automatically. 
    That process is known as <i>binding</i> -- creating classes that recognize 
    and process different data elements by processing the specification that defines 
    those elements. As time goes on, you should find that you are using the data 
    specification to generate significant chunks of code, so you can focus on 
    the programming that is unique to your application.</p>
  <p></p>
  <h4><a name="archiving"></a>Archiving</h4>
  <p>The Holy Grail of programming is the construction of reusable, modular components. 
    Ideally, you'd like to take them off the shelf, customize them, and plug them 
    together to construct an application, with a bare minimum of additional coding 
    and additional compilation.</p>
  <p>The basic mechanism for saving information is called <i>archiving</i>. You 
    archive a component by writing it to an output stream in a form that you can 
    reuse later. You can then read it in and instantiate it using its saved parameters. 
    (For example, if you saved a table component, its parameters might be the 
    number of rows and columns to display.) Archived components can also be shuffled 
    around the Web and used in a variety of ways. </p>
  <p>When components are archived in binary form, however, there are some limitations 
    on the kinds of changes you can make to the underlying classes if you want 
    to retain compatibility with previously saved versions. If you could modify 
    the archived version to reflect the change, that would solve the problem. 
    But that's hard to do with a binary object. Such considerations have prompted 
    a number of investigations into using XML for archiving. But if an object's 
    state were archived in text form using XML, then anything and everything in 
    it could be changed as easily as you can say, &quot;search and replace&quot;. 
  </p>
  <p>XML's text-based format could also make it easier to transfer objects between 
    applications written in different languages. For all of these reasons, XML-based 
    archiving is likely to become an important force in the not-too-distant future.</p>
  <h3>Summary</h3>
  <p>XML is pretty simple, and very flexible. It has many uses yet to be discovered 
    -- we are just beginning to scratch the surface of its potential. It is the 
    foundation for a great many standards yet to come, providing a common language 
    that different computer systems can use to exchange data with one another. 
    As each industry-group comes up with standards for what they want to say, 
    computers will begin to link to each other in ways previously unimaginable. 
  </p>
  <p>For more information on the background and motivation of XML, see this great 
    article in Scientific American at <a href="http://www.sciam.com/1999/0599issue/0599bosak.html"><code>http://www.sciam.com/1999/0599issue/0599bosak.html</code></a>.</p>
  <p></p>
  <h5></h5>
  <hr size=4>
</blockquote>
<p>
<p> 
<table width="100%">
<tr>
    <td align=left> <a href="index.html"><img src="../images/PreviousArrow.gif" width=26 height=26 align=bottom border=0 alt="Previous | "></a><a
href="2_specs.html"><img src="../images/NextArrow.gif" width=26 height=26 align=bottom border=0 alt="Next | "></a><a href="../alphaIndex.html"><img src="../images/xml_IDX.gif" width=26 height=26 align=bottom border=0 alt="Index | "></a><a href="../TOC.html"><img
src="../images/xml_TOC.gif" width=26 height=26 align=bottom border=0 alt="TOC | "></a><a href="../index.html"><img
src="../images/xml_Top.gif" width=26 height=26 align=bottom border=0 alt="Top | "></a> 
    </td>
    <td align=right><strong><em><a href="index.html">Top</a></em></strong> <a href="../TOC.html#intro"><strong><em></em></strong></a> <a href="../TOC.html#intro"><strong><em>Contents</em></strong></a>  
      <a href="../alphaIndex.html"><strong><em>Index</em></strong></a> <a href="../glossary.html"><strong><em>Glossary</em></strong></a>
    </td>
</tr>
</table>
</body>
</html>