4_design.html

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

  why.</p>
<p>Defining a sense of style for XML is, unfortunately, as nebulous a business 
  as defining &quot;style&quot; when it comes to art or music. There are a few 
  ways to approach it, however. The goal of this section is to give you some useful 
  thoughts on the subject of &quot;XML style&quot;. </p>
<dl> 
  <dl> 
    <dt><b>Visibility</b></dt>
    <dd>The first heuristic for thinking about XML elements and attributes uses 
      the concept of <i>visibility</i>. If the data is intended to be shown -- 
      to be displayed to some end user -- then it should be modeled as an element. 
      On the other hand, if the information guides XML processing but is never 
      displayed, then it may be better to model it as an attribute. For example, 
      in order-entry data for shoes, shoe size would definitely be an element. 
      On the other hand, a manufacturer's code number would be reasonably modeled 
      as an attribute.</dd>
    <dt>&nbsp;</dt>
    <dt><b>Consumer / Provider</b></dt>
    <dd>Another way of thinking about the visibility heuristic is to ask who is 
      the consumer and/or provider of the information. The shoe size is entered 
      by a human sales clerk, so it's an element. The manufacturer's code number 
      for a given shoe model, on the other hand, may be wired into the application 
      or stored in a database, so that would be an attribute. (If it were entered 
      by the clerk, though, it should perhaps be an element.) You can also think 
      in terms of who or what is processing the information. Things can get a 
      bit murky at that end of the process, however. If the information &quot;consumers&quot; 
      are order-filling clerks, will they need to see the manufacturer's code 
      number? Or, if an order-filling program is doing all the processing, which 
      data items should be elements in that case? Such philosophical distinctions 
      leave a lot of room for differences in style. </dd>
    <dd>&nbsp;</dd>
    <dt><b>Container vs. Contents</b></dt>
    <dd>Another way of thinking about elements and attributes is to think of an 
      element as a <i>container</i>. To reason by analogy, the <i>contents</i> 
      of the container (water or milk) correspond to XML data modeled as elements. 
      On the other hand, <i>characteristics</i> of the container (blue or white, 
      pitcher or can) correspond to XML data modeled as attributes. Good XML style 
      will, in some consistent way, separate each container's contents from its 
      characteristics. </dd>
  </dl>
</dl>
<p>To show these heuristics at work: In a slideshow the type of the slide (executive 
  or technical) is best modeled as an attribute. It is a characteristic of the 
  slide that lets it be selected or rejected for a particular audience. The title 
  of the slide, on the other hand, is part of its contents. The visibility heuristic 
  is also satisfied here. When the slide is displayed, the title is shown but 
  the type of the slide isn't. Finally, in this example, the consumer of the title 
  information is the presentation audience, while the consumer of the type information 
  is the presentation program.</p>
<h3><a name="normalizingData"></a>Normalizing Data</h3>
<p>In the SAX tutorial, the section <a href="../sax/5c_dtd.html">Defining Attributes 
  and Entities in the DTD</a> shows how to create an <a href="../glossary.html#externalEntity">external 
  entity</a> that you can reference in an XML document. Such an entity has all 
  the advantages of a modularized routine -- changing that one copy affects every 
  document that references it. The process of eliminating redundancies is known 
  as <i>normalizing</i>, so defining entities is one good way to normalize your 
  data. </p>
<p>In an HTML file, the only way to achieve that kind of modularity is with HTML 
  links -- but of course the document is then fragmented, rather than whole. XML 
  entities, on the other hand, suffer no such fragmentation. The entity reference 
  acts like a macro -- the entity's contents are expanded in place, producing 
  a whole document, rather than a fragmented one. And when the entity is defined 
  in an external file, multiple documents can reference it. </p>
<p>The considerations for defining an entity reference, then, are pretty much 
  the same as those you would apply to modularize program code:</p>
<ol>
  <li> 
    <p> Whenever you find yourself writing the same thing more than once, think 
      <a href="../glossary.html#entity">entity</a>. <br>
      That lets you write it one place and reference it multiple places.</p>
  </li>
  <li> 
    <p>If the information is likely to change, especially if it is used in more 
      than one place, definitely think in terms of defining an entity. An example 
      is defining <code>productName</code> as an entity so that you can easily 
      change the documents when the product name changes. </p>
  </li>
  <li> 
    <p>If the entity will never be referenced anywhere except in the current file, 
      define it in the <a href="../glossary.html#localSubset">local_subset</a> 
      of the document's DTD, much as you would define a method or inner class 
      in a program. </p>
  </li>
  <li> 
    <p>If the entity will be referenced from multiple documents, define it as 
      an external entity, the same way that would define any generally usable 
      class as an external class.</p>
  </li>
</ol>
<p>External entities produce modular XML that is smaller, easier to update and 
  maintain. They can also make the resulting document somewhat more difficult 
  to visualize, much as a good OO design can be easy to change, once you understand 
  it, but harder to wrap your head around at first.</p>
<p> You can also go overboard with entities. At an extreme, you could make an 
  entity reference for the word &quot;the&quot; -- it wouldn't buy you much, but 
  you could do it.</p>
<blockquote> 
  <p><b>Note:</b><br>
    The larger an entity is, the less likely it is that changing it will have 
    unintended effects. When you define an external entity that covers a whole 
    section on installation instructions, for example, making changes to the section 
    is unlikely to make any of the documents that depend on it come out wrong. 
    Small inline substitutions can be more problematic, though. For example, if 
    <code>productName</code> is defined as an entity, the name change can be to 
    a different part of speech, and that can kill you! Suppose the product name 
    is something like &quot;HtmlEdit&quot;. That's a verb. So you write, &quot;You 
    can HtmlEdit your file...&quot;. Then, when the official name is decided, 
    it's &quot;Killer&quot;. After substitution, that becomes &quot;You can Killer 
    your file...&quot;. Argh. Still, even if such simple substitutions can sometimes 
    get you in trouble, they can also save a lot of work. To be totally safe, 
    though, you could set up entities named <code>productNoun</code>, <code>productVerb</code>, 
    <code>productAdj</code>, and <code>productAdverb</code>!</p>
</blockquote>
<p></p>
<h3><a name="normalizingDTDs"></a>Normalizing DTDs</h3>
<p> Just as you can normalize your XML document, you can also normalize your DTD 
  declarations by factoring out common pieces and referencing them with a <a href="../glossary.html#parameterEntity">parameter 
  entity</a>. This process is described in the SAX tutorial in <a href="../sax/7a_pe.html">Defining 
  Parameter Entities</a>. Factoring out the DTDs (also known as modularizing or 
  normalizing) gives the same advantages and disadvantages as normalized XML -- 
  easier to change, somewhat more difficult to follow.</p>
<p>You can also set up conditionalized DTDs, as described in the SAX tutorial 
  section <a href="../sax/7a_pe.html#conditionals">Conditional Sections</a>. If 
  the number and size of the conditional sections is small relative to the size 
  of the DTD as a whole, that can let you &quot;single source&quot; a DTD that 
  you can use for multiple purposes. If the number of conditional sections gets 
  large, though, the result can be a complex document that is difficult to edit.</p>
<blockquote>
  <hr size=4>
</blockquote>
<p> 
<p> 
<table width="100%">
  <tr> 
    <td align=left> <a href="3_apis.html"><img src="../images/PreviousArrow.gif" width=26 height=26 align=top border=0 alt="Previous | "></a><a
href="index.html"><img src="../images/NextArrow.gif" width=26 height=26 align=top border=0 alt="Next | "></a><a href="../alphaIndex.html"><img src="../images/xml_IDX.gif" width=26 height=26 align=top border=0 alt="Index | "></a><a href="../TOC.html"><img
src="../images/xml_TOC.gif" width=26 height=26 align=top border=0 alt="TOC | "></a><a href="../index.html"><img
src="../images/xml_Top.gif" width=26 height=26 align=top 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>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>