📄 introxml5.html
字号:
<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> <meta http-equiv="Content-Style-Type" content="text/css" /> <title>Designing an XML Data Structure</title> <link rel="StyleSheet" href="document.css" type="text/css" media="all" /> <link rel="StyleSheet" href="catalog.css" type="text/css" media="all" /> <link rel="Table of Contents" href="J2EETutorialTOC.html" /> <link rel="Previous" href="IntroXML4.html" /> <link rel="Next" href="WebApp.html" /> <link rel="Index" href="J2EETutorialIX.html" /> </head> <body> <table width="550" summary="layout" id="SummaryNotReq1"> <tr> <td align="left" valign="center"> <font size="-1"> <a href="http://java.sun.com/j2ee/1.4/download.html#tutorial" target="_blank">Download</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/faq.html" target="_blank">FAQ</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/history.html" target="_blank">History</a> </td> <td align="center" valign="center"><a accesskey="p" href="IntroXML4.html"><img id="LongDescNotReq1" src="images/PrevArrow.gif" width="26" height="26" border="0" alt="Prev" /></a><a accesskey="c" href="J2EETutorialFront.html"><img id="LongDescNotReq1" src="images/UpArrow.gif" width="26" height="26" border="0" alt="Home" /></a><a accesskey="n" href="WebApp.html"><img id="LongDescNotReq3" src="images/NextArrow.gif" width="26" height="26" border="0" alt="Next" /></a><a accesskey="i" href="J2EETutorialIX.html"></a> </td> <td align="right" valign="center"> <font size="-1"> <a href="http://java.sun.com/j2ee/1.4/docs/api/index.html" target="_blank">API</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/search.html" target="_blank">Search</a> <br> <a href="http://java.sun.com/j2ee/1.4/docs/tutorial/information/sendusmail.html" target="_blank">Feedback</a></font> </font> </td> </tr> </table> <img src="images/blueline.gif" width="550" height="8" ALIGN="BOTTOM" NATURALSIZEFLAG="3" ALT="Divider"> <blockquote><a name="wp64992"> </a><h2 class="pHeading1">Designing an XML Data Structure</h2><a name="wp64993"> </a><p class="pBody">This section covers some heuristics you can use when making XML design decisions. </p><a name="wp64995"> </a><h3 class="pHeading2">Saving Yourself Some Work </h3><a name="wp64996"> </a><p class="pBody">Whenever possible, use an existing schema definition. It's usually a lot easier to ignore the things you don't need than to design your own from scratch. In addition, using a standard DTD makes data interchange possible, and may make it possible to use data-aware tools developed by others. </p><a name="wp64997"> </a><p class="pBody">So, if an industry standard exists, consider referencing that DTD with an external parameter entity. One place to look for industry-standard DTDs is at the web site created by the Organization for the Advancement of Structured Information Standards (OASIS). You can find a list of technical committees at <code class="cCode"><a href="http://www.oasis-open.org/" target="_blank">http://www.oasis-open.org/</a></code>, or check their repository of XML standards at <code class="cCode"><a href="http://www.XML.org" target="_blank">http://www.XML.org</a></code>.</p><hr><a name="wp64998"> </a><p class="pNote">Note: Many more good thoughts on the design of XML structures are at the OASIS page, <code class="cCode"><a href="http://www.oasis-open.org/cover/elementsAndAttrs.html" target="_blank">http://www.oasis-open.org/cover/elementsAndAttrs.html</a></code>.</p><hr><a name="wp65003"> </a><h3 class="pHeading2">Attributes and Elements</h3><a name="wp65004"> </a><p class="pBody">One of the issues you will encounter frequently when designing an XML structure is whether to model a given data item as a subelement or as an attribute of an existing element. For example, you could model the title of a slide either as:</p><div class="pPreformattedRelative"><pre class="pPreformattedRelative"><slide> <title>This is the title</title></slide><a name="wp65005"> </a></pre></div><a name="wp65006"> </a><p class="pBody">or as:</p><div class="pPreformattedRelative"><pre class="pPreformattedRelative"><slide title="This is the title">...</slide><a name="wp65007"> </a></pre></div><a name="wp65008"> </a><p class="pBody">In some cases, the different characteristics of attributes and elements make it easy to choose. Let's consider those cases first, and then move on to the cases where the choice is more ambiguous.</p><a name="wp65010"> </a><h4 class="pHeading3">Forced Choices</h4><a name="wp65011"> </a><p class="pBody">Sometimes, the choice between an attribute and an element is forced on you by the nature of attributes and elements. Let's look at a few of those considerations:</p><a name="wp65012"> </a><p class="pDefinitionTerm">The data contains substructures</p><a name="wp65013"> </a><p class="pDefinition">In this case, the data item must be modeled as an <span style="font-style: italic">element</span>. It can't be modeled as an attribute, because attributes take only simple strings. So if the title can contain emphasized text like this: <code class="cCode">The <em>Best</em> Choice</code>, then the title must be an element.</p><a name="wp65014"> </a><p class="pDefinitionTerm">The data contains multiple lines</p><a name="wp65015"> </a><p class="pDefinition">Here, it also makes sense to use an <span style="font-style: italic">element</span>. Attributes need to be simple, short strings or else they become unreadable, if not unusable.</p><a name="wp66777"> </a><p class="pDefinitionTerm">Multiple occurrences are possible</p><a name="wp66778"> </a><p class="pDefinition">Whenever an item can occur multiple times, like paragraphs in an article, it must be modeled as an <span style="font-style: italic">element</span>. The element that contains it can only have one attribute of a particular kind, but it can have many subelements of the same type.</p><a name="wp65016"> </a><p class="pDefinitionTerm">The data changes frequently</p><a name="wp65017"> </a><p class="pDefinition">When the data will be frequently modified with an editor, it may make sense to model it as an <span style="font-style: italic">element</span>. Many XML-aware editors make it easy modify element data, while attributes can be somewhat harder to get to.</p><a name="wp65018"> </a><p class="pDefinitionTerm">The data is a small, simple string that rarely if ever changes</p><a name="wp65019"> </a><p class="pDefinition">This is data that can be modeled as an <span style="font-style: italic">attribute</span>. However, just because you <span style="font-style: italic">can</span> does not mean that you should. Check the "Stylistic Choices" section next, to be sure.</p><a name="wp65020"> </a><p class="pDefinitionTerm">Using DTDs when the data is confined to a small number of fixed choices</p><a name="wp65021"> </a><p class="pDefinition">Here is one time when it really makes sense to use an <span style="font-style: italic">attribute</span>. A DTD can prevent an attribute from taking on any value that is not in the preapproved list, but it cannot similarly restrict an element. (With a schema on the other hand, both attributes and elements can be restricted.) </p><a name="wp65023"> </a><h4 class="pHeading3">Stylistic Choices</h4><a name="wp65024"> </a><p class="pBody">As often as not, the choices are not as cut and dried as those shown above. When the choice is not forced, you need a sense of "style" to guide your thinking. The question to answer, then, is what makes good XML style, and why.</p><a name="wp65025"> </a><p class="pBody">Defining a sense of style for XML is, unfortunately, as nebulous a business as defining "style" 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 "XML style". </p><a name="wp65026"> </a><p class="pDefinitionTerm">Visibility</p><a name="wp65027"> </a><p class="pDefinition">One heuristic for thinking about XML elements and attributes uses the concept of <span style="font-style: italic">visibility</span>. 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 seen by a user, 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.</p><a name="wp65028"> </a><p class="pDefinitionTerm">Consumer / Provider</p><a name="wp65029"> </a><p class="pDefinition">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.)</p><a name="wp65030"> </a><p class="pDefinitionTerm">Container vs. Contents</p><a name="wp65031"> </a><p class="pDefinition">Perhaps the best way of thinking about elements and attributes is to think of an element as a <span style="font-style: italic">container</span>. To reason by analogy, the <span style="font-style: italic">contents</span> of the container (water or milk) correspond to XML data modeled as elements. Such data is essentially variable. On the other hand, <span style="font-style: italic">characteristics</span> of the container (blue or white pitcher) can be modeled as attributes. That kind of information tends to be more immutable. Good XML style will, in some consistent way, separate each container's contents from its characteristics. </p><a name="wp65032"> </a><p class="pBody">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><a name="wp65034"> </a><h3 class="pHeading2">Normalizing Data</h3><a name="wp65038"> </a><p class="pBody">In <a href="IntroXML5.html#wp64995">Saving Yourself Some Work</a>, you saw that it is a good idea to define an external entity 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 <span style="font-style: italic">normalizing</span>, so defining entities is one good way to normalize your data. </p><a name="wp65039"> </a><p class="pBody">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><a name="wp65040"> </a><p class="pBody">The considerations for defining an entity reference, then, are pretty much the same as those you would apply to modularized program code:</p><div class="pSmartList1"><ul class="pSmartList1"><a name="wp65041"> </a><div class="pSmartList1"><li>Whenever you find yourself writing the same thing more than once, think entity. That lets you write it one place and reference it multiple places.</li></div><a name="wp65042"> </a><div class="pSmartList1"><li>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 class="cCode">productName</code> as an entity so that you can easily change the documents when the product name changes. </li></div><a name="wp65043"> </a><div class="pSmartList1"><li>If the entity will never be referenced anywhere except in the current file, define it in the local_subset of the document's DTD, much as you would define a method or inner class in a program. </li></div><a name="wp65044"> </a><div class="pSmartList1"><li>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.</li></div></ul></div>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -