introxml3.html

j2eePDF格式的电子书

Schema Standards
</h3>
<a name="wp71946"> </a><p class="pBody">
A DTD makes it possible to validate the structure of relatively simple XML documents, but that's as far as it goes. 
</p>
<a name="wp71947"> </a><p class="pBody">
A DTD can't restrict the content of elements, and it can't specify complex relationships. For example, it is impossible to specify that a &lt;heading&gt; for a &lt;book&gt; must have both a &lt;title&gt; and an &lt;author&gt;, while a &lt;heading&gt; for a &lt;chapter&gt; only needs a &lt;title&gt;. In a DTD, you only get to specify the structure of the &lt;heading&gt; element one time. There is no context-sensitivity, because a DTD specification is not hierarchical.
</p>
<a name="wp71978"> </a><p class="pBody">
For example, for a mailing address that contains several &quot;parsed character data&quot; (PCDATA) elements, the DTD might look something like this:
</p>
<div class="pPreformattedRelative"><pre class="pPreformattedRelative">
&lt;!ELEMENT mailAddress (<span style="font-weight: bold">name</span>, address, zipcode)&gt;
&lt;!ELEMENT <span style="font-weight: bold">name</span> (#PCDATA)&gt;
&lt;!ELEMENT address (#PCDATA)&gt;
&lt;!ELEMENT zipcode (#PCDATA)&gt;<a name="wp71949"> </a>
</pre></div>
<a name="wp71950"> </a><p class="pBody">
As you can see, the specifications are linear. So if you need another &quot;name&quot; element in the DTD, you need a different identifier for it. You could not simply call it &quot;name&quot; without conflicting with the &lt;name&gt; element defined for use in a &lt;mailAddress&gt;. 
</p>
<a name="wp71951"> </a><p class="pBody">
Another problem with the non hierarchical nature of DTD specifications is that it is not clear what comments are meant to explain. A comment at the top like might be intended to apply to the whole structure, or it might be intended only for the first item. Finally, DTDs do not allow you to formally specify field-validation criteria, such as the 5-digit (or 5 and 4) limitation for the <code class="cCode">zipcode</code> field.
</p>
<a name="wp71952"> </a><p class="pBody">
Finally, a DTD uses syntax which is substantially different from XML, so it can't be processed with a standard XML parser. That means you can't read a DTD into a DOM, for example, modify it, and then write it back out again.
</p>
<a name="wp71953"> </a><p class="pBody">
To remedy these shortcomings, a number of proposals have been made for a more database-like, hierarchical &quot;schema&quot; that specifies validation criteria. The major proposals are shown below.
</p>
<a name="wp71956"> </a><h4 class="pHeading3">
XML Schema 
</h4>
<a name="wp71957"> </a><p class="pBody">
A large, complex standard that has two parts. One part specifies structure relationships. (This is the largest and most complex part.) The other part specifies mechanisms for validating the content of XML elements by specifying a (potentially very sophisticated) <span style="font-style: italic">datatype</span> for each element. The good news is that XML Schema for Structures lets you specify virtually any relationship you can conceive. The bad news is that it is very difficult to implement, and it's hard to learn. Most of the alternatives provide for simpler structure definitions, while incorporating XML Schema's datatyping mechanisms.
</p>
<a name="wp71959"> </a><p class="pBody">
For more information on XML Schema, see the W3C specs XML Schema (Structures) and XML Schema (Datatypes), as well as other information accessible at <code class="cCode"><a  href="http://www.w3c.org/XML/Schema" target="_blank">http://www.w3c.org/XML/Schema</a></code>. 
</p>
<a name="wp71963"> </a><h4 class="pHeading3">
RELAX NG
</h4>
<a name="wp71964"> </a><p class="pBody">
REgular LAnguage description for XML (Next Generation)
</p>
<a name="wp71965"> </a><p class="pBody">
Simpler than XML Structure Schema, RELAX NG is an emerging standard under the auspices of OASIS (Organization for the Advancement of Structured Information Systems). It may become an ISO standard in the near future, as well. 
</p>
<a name="wp72046"> </a><p class="pBody">
RELAX NG uses regular expression patterns to express constraints on structure relationships, and it is uses XML Schema datatyping mechanisms to express content constraints. This standard also uses XML syntax, and it includes a DTD to RELAX converter. (It's &quot;next generation&quot; because it's a newer version of the RELAX schema mechanism that integrates <a  href="IntroXML3.html#wp66583">TREX</a>.)
</p>
<a name="wp71970"> </a><p class="pBody">
For more information on RELAX NG, see <code class="cCode"><a  href="http://www.oasis-open.org/committees/relax-ng/" target="_blank">http://www.oasis-open.org/committees/relax-ng/</a></code>
</p>
<a name="wp66583"> </a><h4 class="pHeading3">
TREX
</h4>
<a name="wp66584"> </a><p class="pBody">
Tree Regular Expressions for XML
</p>
<a name="wp66585"> </a><p class="pBody">
A means of expressing validation criteria by describing a <span style="font-style: italic">pattern</span> for the structure and content of an XML document. Now part of the <a  href="IntroXML3.html#wp71963"></a><a  href="IntroXML3.html#wp71963">RELAX NG</a> specification.
</p>
<a name="wp66593"> </a><p class="pBody">
For more information on TREX, see <code class="cCode"><a  href="http://www.thaiopensource.com/trex/" target="_blank">http://www.thaiopensource.com/trex/</a></code>.
</p>
<a name="wp64180"> </a><h4 class="pHeading3">
SOX
</h4>
<a name="wp64181"> </a><p class="pBody">
Schema for Object-oriented XML
</p>
<a name="wp64182"> </a><p class="pBody">
SOX is a schema proposal that includes extensible data types, namespaces, and embedded documentation.
</p>
<a name="wp64183"> </a><p class="pBody">
For more information on SOX, see <code class="cCode"><a  href="http://www.w3.org/TR/NOTE-SOX" target="_blank">http://www.w3.org/TR/NOTE-SOX</a></code>.
</p>
<a name="wp64190"> </a><h4 class="pHeading3">
Schematron
</h4>
<a name="wp64191"> </a><p class="pBody">
Schema for Object-oriented XML
</p>
<a name="wp64192"> </a><p class="pBody">
An assertion-based schema mechanism that allows for sophisticated validation.
</p>
<a name="wp64193"> </a><p class="pBody">
For more information on the Schematron validation mechanism, see <code class="cCode"><a  href="http://www.ascc.net/xml/resource/schematron/schematron.html" target="_blank">http://www.ascc.net/xml/resource/schematron/schematron.html</a></code>.
</p>
<a name="wp64195"> </a><h3 class="pHeading2">
Linking and Presentation Standards
</h3>
<a name="wp64196"> </a><p class="pBody">
Arguably the two greatest benefits provided by HTML were the ability to link between documents, and the ability to create simple formatted documents (and, eventually, very complex formatted documents). The following standards aim at preserving the benefits of HTML in the XML arena, and to adding additional functionality, as well.    
</p>
<a name="wp64198"> </a><h4 class="pHeading3">
XML Linking
</h4>
<a name="wp64199"> </a><p class="pBody">
These specifications provide a variety of powerful linking mechanisms, and are sure to have a big impact on how XML documents are used. 
</p>
<a name="wp64201"> </a><p class="pDefinitionTerm">
 XLink
</p>
<a name="wp64202"> </a><p class="pDefinition">
The XLink protocol is a specification for handling links between XML documents. This specification allows for some pretty sophisticated linking, including two-way links, links to multiple documents, &quot;expanding&quot; links that insert the linked information into your document rather than replacing your document with a new page, links between two documents that are created in a third, independent document, and indirect links (so you can point to an &quot;address book&quot; rather than directly to the target document--updating the address book then automatically changes any links that use it). 
</p>
<a name="wp64204"> </a><p class="pDefinitionTerm">
XML Base
</p>
<a name="wp64205"> </a><p class="pDefinition">
This standard defines an attribute for XML documents that defines a &quot;base&quot; address, that is used when evaluating a relative address specified in the document. (So, for example, a simple file name would be found in the base-address directory.)
</p>
<a name="wp64207"> </a><p class="pDefinitionTerm">
XPointer
</p>
<a name="wp64208"> </a><p class="pDefinition">
In general, the XLink specification targets a document or document-segment using its ID. The XPointer specification defines mechanisms for &quot;addressing into the internal structures of XML documents&quot;, without requiring the author of the document to have defined an ID for that segment. To quote the spec, it provides for &quot;reference to elements, character strings, and other parts of XML documents, whether or not they bear an explicit ID attribute&quot;.
</p>
<a name="wp64209"> </a><p class="pBody">
For more information on the XML Linking standards, see <code class="cCode"><a  href="http://www.w3.org/XML/Linking" target="_blank">http://www.w3.org/XML/Linking</a></code>.
</p>
<a name="wp64211"> </a><h4 class="pHeading3">
XHTML
</h4>
<a name="wp64212"> </a><p class="pBody">
The XHTML specification is a way of making XML documents that look and act like HTML documents. Since an XML document can contain any tags you care to define, why not define a set of tags that look like HTML? That's the thinking behind the XHTML specification, at any rate. The result of this specification is a document that can be displayed in browsers and also treated as XML data. The data may not be quite as identifiable as &quot;pure&quot; XML, but it will be a heck of a lot easier to manipulate than standard HTML, because XML specifies a good deal more regularity and consistency. 
</p>
<a name="wp64213"> </a><p class="pBody">
For example, every tag in a well-formed XML document must either have an end-tag associated with it or it must end in <code class="cCode">/&gt;</code>. So you might see <code class="cCode">&lt;p&gt;...&lt;/p&gt;</code>, or you might see <code class="cCode">&lt;p/&gt;</code>, but you will never see <code class="cCode">&lt;p&gt;</code> standing by itself. The upshot of that requirement is that you never have to program for the weird kinds of cases you see in HTML where, for example, a <code class="cCode">&lt;dt&gt;</code> tag might be terminated by <code class="cCode">&lt;/DT&gt;</code>, by another <code class="cCode">&lt;DT&gt;</code>, by <code class="cCode">&lt;dd&gt;</code>, or by <code class="cCode">&lt;/dl&gt;</code>. That makes it a lot easier to write code!
</p>
<a name="wp64214"> </a><p class="pBody">
The XHTML specification is a reformulation of HTML 4.0 into XML. The latest information is at <code class="cCode"><a  href="http://www.w3.org/TR/xhtml1" target="_blank">http://www.w3.org/TR/xhtml1</a></code>.
</p>
<a name="wp64216"> </a><h3 class="pHeading2">
Knowledge Standards
</h3>
<a name="wp64217"> </a><p class="pBody">
When you start looking down the road five or six years, and visualize how the information on the Web will begin to turn into one huge knowledge base (the &quot;semantic Web&quot;). For the latest on the semantic Web, visit <code class="cCode"><a  href="http://www.w3.org/2001/sw/" target="_blank">http://www.w3.org/2001/sw/</a></code>. 
</p>
<a name="wp64218"> </a><p class="pBody">
In the meantime, here are the fundamental standards you'll want to know about:    
</p>
<a name="wp64220"> </a><h4 class="pHeading3">
RDF 
</h4>
<a name="wp64221"> </a><p class="pBody">
Resource Description Framework
</p>
<a name="wp64222"> </a><p class="pBody">
RDF is a standard for defining <span style="font-style: italic">meta</span> data--information that describes what a particular data item is, and specifies how it can be used. Used in conjunction with the XHTML specification, for example, or with HTML pages, RDF could be used to describe the content of the pages. For example, if your browser stored your ID information as <code class="cCode">FIRSTNAME</code>, <code class="cCode">LASTNAME</code>, and <code class="cCode">EMAIL</code>, an RDF description could make it possible to transfer data to an application that wanted <code class="cCode">NAME</code> and <code class="cCode">EMAILADDRESS</code>. Just think: One day you may not need to type your name and address at every Web site you visit!
</p>
<a name="wp64223"> </a><p class="pBody">
For the latest information on RDF, see <code class="cCode"><a  href="http://www.w3.org/TR/REC-rdf-syntax" target="_blank">http://www.w3.org/TR/REC-rdf-syntax</a></code>.
</p>
<a name="wp64225"> </a><h4 class="pHeading3">
RDF Schema 
</h4>
<a name="wp64226"> </a><p class="pBody">
RDF Schema allows the specification of consistency rules and additional information that describe how the statements in a Resource Description Framework (RDF) should be interpreted. 
</p>
<a name="wp64227"> </a><p class="pBody">
For more information on the RDF Schema recommendation, see <code class="cCode"><a  href="http://www.w3.org/TR/rdf-schema" target="_blank">http://www.w3.org/TR/rdf-schema</a></code>.
</p>
<a name="wp64229"> </a><h4 class="pHeading3">
XTM
</h4>
<a name="wp64230"> </a><p class="pBody">
XML Topic Maps
</p>
<a name="wp64231"> </a><p class="pBody">
In many ways a simpler, more readily usable knowledge-representation than RDF, the topic maps standard is one worth watching. So far, RDF is the W3C standard for knowledge representation, but topic maps could possibly become the &quot;developer's choice&quot; among knowledge representation standards. 
</p>
<a name="wp64232"> </a><p class="pBody">