This specification defines XHTML 1.0, a reformulation of HTML
+4.0 as an XML 1.0 application, and three DTDs corresponding to
+the ones defined by HTML 4.0. The semantics of the elements and
+their attributes are defined in the W3C Recommendation for HTML
+4.0. These semantics provide the foundation for future
+extensibility of XHTML. Compatibility with existing HTML user
+agents is possible by following a small set of guidelines.
+
+
Status of this document
+
+
This section describes the status of this document at the time
+of its publication. Other documents may supersede this document. The
+latest status of this document series is maintained at the W3C.
+
+
This specification is a Proposed Recommendation of the HTML Working Group. It is
+a revision of the Proposed Recommendation dated 24 August
+1999 incorporating changes as a result of comments from the Proposed
+Recommendation review, and
+comments and further deliberations of the W3C HTML Working Group. A
+diff-marked version from the previous
+proposed recommendation is available for comparison purposes.
+
+
On 10 December 1999, this document enters a
+
+Proposed Recommendation review period. From that date until 8 January
+2000,
+W3C Advisory Committee representatives are encouraged
+to review this specification and return comments in their completed
+ballots to w3c-html-review@w3.org. Please send any comments of a
+confidential nature in separate email to w3t-html@w3.org, which is
+visible to the Team only.
+
+
No sooner than 14 days after the end of the review period, the
+Director will announce the document's disposition: it may become a W3C
+Recommendation (possibly with minor changes), it may revert to Working
+Draft status, or it may be dropped as a W3C work item.
+
+
Publication as a Proposed Recommendation does not imply endorsement
+by the W3C membership. This is still a draft document and may be
+updated, replaced or obsoleted by other documents at any time. It is
+inappropriate to cite W3C Proposed Recommendation as other than "work
+in progress."
A list of current W3C Recommendations and other technical documents
+can be found at http://www.w3.org/TR.
+
+
Public discussion on HTML features takes place on the mailing list www-html@w3.org (archive). The W3C
+staff contact for work on HTML is Dave
+Raggett.
XHTML is a family of current and future document types and modules that
+reproduce, subset, and extend HTML 4.0 [HTML]. XHTML family document types are XML based,
+and ultimately are designed to work in conjunction with XML-based user agents.
+The details of this family and its evolution are
+discussed in more detail in the section on Future
+Directions.
+
+
XHTML 1.0 (this specification) is the first document type in the XHTML
+family. It is a reformulation of the three HTML 4.0 document types as
+applications of XML 1.0 [XML]. It is intended
+to be used as a language for content that is both XML-conforming and, if some
+simple guidelines are followed,
+operates in HTML 4.0 conforming user agents. Developers who migrate
+their content to XHTML 1.0 will realize the following benefits:
+
+
+
XHTML documents are XML conforming. As such, they are readily viewed,
+edited, and validated with standard XML tools.
+
XHTML documents can be written to
+to operate as well or better than they did before in existing
+HTML 4.0-conforming user agents as well as in new, XHTML 1.0 conforming user
+agents.
+
XHTML documents can utilize applications (e.g. scripts and applets) that rely
+upon either the HTML Document Object Model or the XML Document Object Model [DOM].
+
As the XHTML family evolves, documents conforming to XHTML 1.0 will be more
+likely to interoperate within and among various XHTML environments.
+
+
+
The XHTML family is the next step in the evolution of the Internet. By
+migrating to XHTML today, content developers can enter the XML world with all
+of its attendant benefits, while still remaining confident in their
+content's backward and future compatibility.
HTML 4.0 [HTML] is an SGML (Standard
+Generalized Markup Language) application conforming to
+International Standard ISO 8879, and is widely regarded as the
+standard publishing language of the World Wide Web.
+
+
SGML is a language for describing markup languages,
+particularly those used in electronic document exchange, document
+management, and document publishing. HTML is an example of a
+language defined in SGML.
+
+
SGML has been around since the middle 1980's and has remained
+quite stable. Much of this stability stems from the fact that the
+language is both feature-rich and flexible. This flexibility,
+however, comes at a price, and that price is a level of
+complexity that has inhibited its adoption in a diversity of
+environments, including the World Wide Web.
+
+
HTML, as originally conceived, was to be a language for the
+exchange of scientific and other technical documents, suitable
+for use by non-document specialists. HTML addressed the problem
+of SGML complexity by specifying a small set of structural and
+semantic tags suitable for authoring relatively simple documents.
+In addition to simplifying the document structure, HTML added
+support for hypertext. Multimedia capabilities were added
+later.
+
+
In a remarkably short space of time, HTML became wildly
+popular and rapidly outgrew its original purpose. Since HTML's
+inception, there has been rapid invention of new elements for use
+within HTML (as a standard) and for adapting HTML to vertical,
+highly specialized, markets. This plethora of new elements has
+led to compatibility problems for documents across different
+platforms.
+
+
As the heterogeneity of both software and platforms rapidly
+proliferate, it is clear that the suitability of 'classic' HTML
+4.0 for use on these platforms is somewhat limited.
XML™ is the shorthand for Extensible Markup
+Language, and is an acronym of Extensible Markup Language [XML].
+
+
XML was conceived as a means of regaining the power and
+flexibility of SGML without most of its complexity. Although a
+restricted form of SGML, XML nonetheless preserves most of SGML's
+power and richness, and yet still retains all of SGML's commonly
+used features.
+
+
While retaining these beneficial features, XML removes many of
+the more complex features of SGML that make the authoring and
+design of suitable software both difficult and costly.
The benefits of migrating to XHTML 1.0 are described above. Some of the
+benefits of migrating to XHTML in general are:
+
+
+
Document developers and user agent designers are constantly
+discovering new ways to express their ideas through new markup. In XML, it is
+relatively easy to introduce new elements or additional element
+attributes. The XHTML family is designed to accommodate these extensions
+through XHTML modules and techniques for developing new XHTML-conforming
+modules (described in the forthcoming XHTML Modularization specification).
+These modules will permit the combination of existing and
+new feature sets when developing content and when designing new user
+agents.
+
+
Alternate ways of accessing the Internet are constantly being
+introduced. Some estimates indicate that by the year 2002, 75% of
+Internet document viewing will be carried out on these alternate
+platforms. The XHTML family is designed with general user agent
+interoperability in mind. Through a new user agent and document profiling
+mechanism, servers, proxies, and user agents will be able to perform
+best effort content transformation. Ultimately, it will be possible to
+develop XHTML-conforming content that is usable by any XHTML-conforming
+user agent.
The following terms are used in this specification. These
+terms extend the definitions in
+[RFC2119] in ways based upon similar definitions in ISO/IEC
+9945-1:1990 [POSIX.1]:
+
+
+
Implementation-defined
+
+
A value or behavior is implementation-defined when it is left
+to the implementation to define [and document] the corresponding
+requirements for correct document construction.
+
+
May
+
+
With respect to implementations, the word "may" is to be
+interpreted as an optional feature that is not required in this
+specification but can be provided. With respect to Document Conformance, the word "may" means that
+the optional feature must not be used. The term "optional" has
+the same definition as "may".
+
+
Must
+
+
In this specification, the word "must" is to be interpreted
+as a mandatory requirement on the implementation or on Strictly
+Conforming XHTML Documents, depending upon the context. The term
+"shall" has the same definition as "must".
+
+
Reserved
+
+
A value or behavior is unspecified, but it is not allowed to
+be used by Conforming Documents nor to be supported by a
+Conforming User Agents.
+
+
Should
+
+
With respect to implementations, the word "should" is to be
+interpreted as an implementation recommendation, but not a
+requirement. With respect to documents, the word "should" is to
+be interpreted as recommended programming practice for documents
+and a requirement for Strictly Conforming XHTML Documents.
+
+
Supported
+
+
Certain facilities in this specification are optional. If a
+facility is supported, it behaves as specified by this
+specification.
+
+
Unspecified
+
+
When a value or behavior is unspecified, the specification
+defines no portability requirements for a facility on an
+implementation even when faced with a document that uses the
+facility. A document that requires specific behavior in such an
+instance, rather than tolerating any behavior when using that
+facility, is not a Strictly Conforming XHTML Document.
An attribute is a parameter to an element declared in the
+DTD. An attribute's type and value range, including a possible
+default value, are defined in the DTD.
+
+
DTD
+
+
A DTD, or document type definition, is a collection of XML
+declarations that, as a collection, defines the legal structure,
+elements, and
+attributes that are available for use in a document that
+complies to the DTD.
+
+
Document
+
+
A document is a stream of data that, after being combined
+with any other streams it references, is structured such that it
+holds information contained within
+elements that are organized as defined in the associated
+DTD. See Document
+Conformance for more information.
+
+
Element
+
+
An element is a document structuring unit declared in the
+DTD. The element's content model is
+defined in the DTD, and additional
+semantics may be defined in the prose description of the
+element.
Functionality includes elements,
+attributes, and the semantics
+associated with those elements and
+attributes. An implementation
+supporting that functionality is said to provide the necessary
+facilities.
+
+
Implementation
+
+
An implementation is a system that provides collection of
+facilities and services that supports
+this specification. See User Agent
+Conformance for more information.
+
+
Parsing
+
+
Parsing is the act whereby a
+document is scanned, and the information contained within
+the document is filtered into the
+context of the elements in which the
+information is structured.
+
+
Rendering
+
+
Rendering is the act whereby the information in a document is presented. This presentation is
+done in the form most appropriate to the environment (e.g.
+aurally, visually, in print).
+
+
User Agent
+
+
A user agent is an implementation
+that retrieves and processes XHTML documents. See User Agent Conformance for more information.
+
+
Validation
+
+
Validation is a process whereby
+documents are verified against the associated DTD, ensuring that the structure, use of elements, and use of
+attributes are consistent with the definitions in the
+DTD.
A document is well-formed when it
+is structured according to the rules defined in Section 2.1 of
+the XML 1.0 Recommendation [XML].
+Basically, this definition states that elements, delimited by
+their start and end tags, are nested properly within one
+another.
This version of XHTML provides a definition of strictly
+conforming XHTML documents, which are restricted to tags and
+attributes from the XHTML namespace. See Section 3.1.2 for information on using XHTML
+with other namespaces, for instance, to include metadata
+expressed in RDF within XHTML documents.
A Strictly Conforming XHTML Document is a document that
+requires only the facilities described as mandatory in this
+specification. Such a document must meet all of the following
+criteria:
+
+
+
+
It must validate against one of the three DTDs found in Appendix A.
+
+
+
+
The root element of the document must be
+<html>.
+
+
+
+
The root element of the document must designate the XHTML
+namespace using the xmlns attribute [XMLNAMES]. The namespace for XHTML is
+defined to be
+http://www.w3.org/1999/xhtml.
+
+
+
+
There must be a DOCTYPE declaration in the document prior to
+the root element. The public identifier included in
+the DOCTYPE declaration must reference one of the three DTDs
+found in Appendix A using the respective
+Formal Public Identifier. The system identifier may be changed to reflect
+local system conventions.
+
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/1999/PR-xhtml1-19991210/DTD/xhtml1-strict.dtd>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/1999/PR-xhtml1-19991210/DTD/xhtml1-transitional.dtd>
+
+<!DOCTYPE html
+ PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
+ "http://www.w3.org/TR/1999/PR-xhtml1-19991210/DTD/xhtml1-frameset.dtd>
+
Note that in this example, the XML declaration is included. An XML
+declaration like the one above is
+not required in all XML documents. XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required
+when the character encoding of the document is other than the default UTF-8 or
+UTF-16.
The XHTML namespace may be used with other XML namespaces
+as per [XMLNAMES], although such
+documents are not strictly conforming XHTML 1.0 documents as
+defined above. Future work by W3C will address ways to specify
+conformance for documents involving multiple namespaces.
+
+
The following example shows the way in which XHTML 1.0 could
+be used in conjunction with the MathML Recommendation:
The following example shows the way in which XHTML 1.0 markup
+could be incorporated into another XML namespace:
+
+
+
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- initially, the default namespace is "books" -->
+<book xmlns='urn:loc.gov:books'
+ xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
+ <title>Cheaper by the Dozen</title>
+ <isbn:number>1568491379</isbn:number>
+ <notes>
+ <!-- make HTML the default namespace for a hypertext commentary -->
+ <p xmlns='http://www.w3.org/1999/xhtml'>
+ This is also available <a href="http://www.w3.org/">online</a>.
+ </p>
+ </notes>
+</book>
+
A conforming user agent must meet all of the following
+criteria:
+
+
+
In order to be consistent with the XML 1.0 Recommendation [XML], the user agent must parse and evaluate
+an XHTML document for well-formedness. If the user agent claims
+to be a validating user agent, it must also validate documents
+against their referenced DTDs according to
+[XML].
+
+
When the user agent claims to support
+facilities defined within this specification or required by
+this specification through normative reference, it must do so in
+ways consistent with the facilities' definition.
+
+
When a user agent processes an XHTML document as generic XML,
+it shall only recognize attributes of type
+ID (e.g. the id attribute on most XHTML elements)
+as fragment identifiers.
+
+
If a user agent encounters an element it does not recognize,
+it must render the element's content.
+
+
If a user agent encounters an attribute it does not
+recognize, it must ignore the entire attribute specification
+(i.e., the attribute and its value).
+
+
If a user agent encounters an attribute value it doesn't
+recognize, it must use the default attribute value.
+
+
If it encounters an entity reference (other than one
+of the predefined entities) for which the User Agent has
+processed no declaration (which could happen if the declaration
+is in the external subset which the User Agent hasn't read), the entity
+reference should be rendered as the characters (starting
+with the ampersand and ending with the semi-colon) that
+make up the entity reference.
+
+
When rendering content, User Agents that encounter
+characters or character entity references that are recognized but not renderable should display the document in such a way that it is obvious to the user that normal rendering has not taken place.
+
+
+The following characters are defined in [XML] as whitespace characters:
+
+
+
Space ( )
+
Tab (	)
+
Carriage return (
)
+
Line feed (
)
+
+
+
+The XML processor normalizes different system's line end codes into one
+single line-feed character, that is passed up to the application. The XHTML
+user agent in addition, must treat the following characters as whitespace:
+
+
+
+
Form feed ()
+
Zero-width space (​)
+
+
+
+In elements where the 'xml:space' attribute is set to 'preserve', the user
+agent must leave all whitespace characters intact (with the exception of
+leading and trailing whitespace characters, which should be removed).
+Otherwise, whitespace
+is handled according to the following rules:
+
+
+
+
+All whitespace surrounding block elements should be removed.
+
+
+Comments are removed entirely and do not affect whitespace handling. One
+whitespace character on either side of a comment is treated as two white
+space characters.
+
+
+Leading and trailing whitespace inside a block element must be removed.
+
+
Line feed characters within a block element must be converted into a
+space (except when the 'xml:space' attribute is set to 'preserve').
+
+
+A sequence of white space characters must be reduced to a single space
+character (except when the 'xml:space' attribute is set to 'preserve').
+
+
+With regard to rendition,
+the User Agent should render the content in a
+manner appropriate to the language in which the content is written.
+In languages whose primary script is Latinate, the ASCII space
+character is typically used to encode both grammatical word boundaries and
+typographic whitespace; in languages whose script is related to Nagari
+(e.g., Sanskrit, Thai, etc.), grammatical boundaries may be encoded using
+the ZW 'space' character, but will not typically be represented by
+typographic whitespace in rendered output; languages using Arabiform scripts
+may encode typographic whitespace using a space character, but may also use
+the ZW space character to delimit 'internal' grammatical boundaries (what
+look like words in Arabic to an English eye frequently encode several words,
+e.g. 'kitAbuhum' = 'kitAbu-hum' = 'book them' == their book); and languages
+in the Chinese script tradition typically neither encode such delimiters nor
+use typographic whitespace in this way.
+
+
+
+
Whitespace in attribute values is processed according to [XML].
Well-formedness is a new concept
+introduced by [XML]. Essentially this
+means that all elements must either have closing tags or be
+written in a special form (as described below), and that all the
+elements must nest.
+
+
Although overlapping is illegal in SGML, it was widely
+tolerated in existing browsers.
XHTML documents must use lower case for all HTML element and
+attribute names. This difference is necessary because XML is
+case-sensitive e.g. <li> and <LI> are different
+tags.
In SGML-based HTML 4.0 certain elements were permitted to omit
+the end tag; with the elements that followed implying closure.
+This omission is not permitted in XML-based XHTML. All elements
+other than those declared in the DTD as EMPTY must
+have an end tag.
+
+
+
CORRECT: terminated elements
+
+
<p>here is a paragraph.</p><p>here is
+another paragraph.</p>
+
+
+
+
INCORRECT: unterminated elements
+
+
<p>here is a paragraph.<p>here is another
+paragraph.
XML does not support attribute minimization. Attribute-value
+pairs must be written in full. Attribute names such as
+compact and checked cannot occur in elements
+without their value being specified.
Empty elements must either have an end tag or the start tag must end with />. For instance,
+<br/> or <hr></hr>. See HTML Compatibility Guidelines for information on ways to
+ensure this is backward compatible with HTML 4.0 user agents.
In attribute values, user agents will strip leading and
+trailing whitespace from attribute values and map sequences
+of one or more whitespace characters (including line breaks) to
+a single inter-word space (an ASCII space character for western
+scripts). See
+Section 3.3.3 of [XML].
In XHTML, the script and style elements are declared as having
+#PCDATA content. As a result, < and
+& will be treated as the start of markup, and
+entities such as < and &
+will be recognized as entity references by the XML processor to
+< and & respectively. Wrapping
+the content of the script or style element within a
+CDATA marked section avoids the expansion of these
+entities.
CDATA sections are recognized by the XML
+processor and appear as nodes in the Document Object Model, see
+
+Section 1.3 of the DOM Level 1 Recommendation [DOM].
+
+
An alternative is to use external script and style
+documents.
SGML gives the writer of a DTD the ability to exclude specific
+elements from being contained within an element. Such
+prohibitions (called "exclusions") are not possible in XML.
+
+
For example, the HTML 4.0 Strict DTD forbids the nesting of an
+'a' element within another 'a' element
+to any descendant depth. It is not possible to spell out such
+prohibitions in XML. Even though these prohibitions cannot be
+defined in the DTD, certain elements should not be nested. A
+summary of such elements and the elements that should not be
+nested in them is found in the normative
+Appendix B.
HTML 4.0 defined the name attribute for the elements
+a,
+applet, frame,
+iframe, img, and map.
+HTML 4.0 also introduced
+the id attribute. Both of these attributes are designed to be
+used as fragment identifiers.
+
In XML, fragment identifiers are of type ID, and
+there can only be a single attribute of type ID per element.
+Therefore, in XHTML 1.0 the id
+attribute is defined to be of type ID. In order to
+ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0
+documents MUST use the id attribute when defining fragment
+identifiers, even on elements that historically have also had a
+name attribute.
+See the HTML Compatibility
+Guidelines for information on ensuring such anchors are backwards
+compatible when serving XHTML documents as media type text/html.
+
+
Note that in XHTML 1.0, the name attribute of these
+elements is formally deprecated, and will be removed in a
+subsequent version of XHTML.
Although there is no requirement for XHTML 1.0 documents to be
+compatible with existing user agents, in practice this is easy to
+accomplish. Guidelines for creating compatible documents can be
+found in Appendix C.
As of the publication of this recommendation, the general
+recommended MIME labeling for XML-based applications
+has yet to be resolved.
+
+
However, XHTML Documents which follow the guidelines set forth
+in Appendix C, "HTML Compatibility Guidelines" may be
+labeled with the Internet Media Type "text/html", as they
+are compatible with most HTML browsers. This document
+makes no recommendation about MIME labeling of other
+XHTML documents.
XHTML 1.0 provides the basis for a family of document types
+that will extend and subset XHTML, in order to support a wide
+range of new devices and applications, by defining modules and
+specifying a mechanism for combining these modules. This
+mechanism will enable the extension and sub-setting of XHTML 1.0
+in a uniform way through the definition of new modules.
As the use of XHTML moves from the traditional desktop user
+agents to other platforms, it is clear that not all of the XHTML
+elements will be required on all platforms. For example a hand
+held device or a cell-phone may only support a subset of XHTML
+elements.
+
+
The process of modularization breaks XHTML up into a series of
+smaller element sets. These elements can then be recombined to
+meet the needs of different communities.
+
+
These modules will be defined in a later W3C document.
A document profile specifies the syntax and semantics of a set
+of documents. Conformance to a document profile provides a basis
+for interoperability guarantees. The document profile specifies
+the facilities required to process documents of that type, e.g.
+which image formats can be used, levels of scripting, style sheet
+support, and so on.
+
+
For product designers this enables various groups to define
+their own standard profile.
+
+
For authors this will obviate the need to write several
+different versions of documents for different clients.
+
+
For special groups such as chemists, medical doctors, or
+mathematicians this allows a special profile to be built using
+standard HTML elements plus a group of elements geared to the
+specialist's needs.
These DTDs and entity sets form a normative part of this
+specification. The complete set of DTD files together with an XML
+declaration and SGML Open Catalog is included in the zip file for this specification.
These DTDs approximate the HTML 4.0 DTDs. It is likely that
+when the DTDs are modularized, a method of DTD construction will
+be employed that corresponds more closely to HTML 4.0.
The XHTML entity sets are the same as for HTML 4.0, but have
+been modified to be valid XML 1.0 entity declarations. Note the
+entity for the Euro currency sign (€ or
+€ or €) is defined
+as part of the special characters.
The following elements have prohibitions on which elements
+they can contain (see Section 4.9). This
+prohibition applies to all depths of nesting, i.e. it contains
+all the descendant elements.
+
+
a
+
+cannot contain other a elements.
+
pre
+
cannot contain the img, object,
+big, small, sub, or
+sup elements.
+
+
button
+
cannot contain the input, select,
+textarea, label, button,
+form, fieldset, iframe or
+isindex elements.
This appendix summarizes design guidelines for authors who
+wish their XHTML documents to render on existing HTML user
+agents.
+
+
C.1 Processing Instructions
+
Be aware that processing instructions are rendered on some
+user agents. However, also note that when the XML declaration is not included
+in a document, the document can only use the default character encodings UTF-8
+or UTF-16.
+
+
C.2 Empty Elements
+
Include a space before the trailing / and
+> of empty elements, e.g.
+<br />,
+<hr /> and <img
+src="karen.jpg" alt="Karen" />. Also, use the
+minimized tag syntax for empty elements, e.g. <br />, as the alternative syntax <br></br> allowed by XML
+gives uncertain results in many existing user agents.
+
+
C.3 Element Minimization and Empty Element Content
+
Given an empty instance of an element whose content model is
+not EMPTY (for example, an empty title or paragraph)
+do not use the minimized form (e.g. use
+<p> </p> and not
+<p />).
+
+
C.4 Embedded Style Sheets and Scripts
+
Use external style sheets if your style sheet uses
+< or & or ]]> or --. Use
+external scripts if your script uses < or
+& or ]]> or --. Note that XML parsers
+are permitted to silently remove the contents of comments. Therefore, the historical
+practice of "hiding" scripts and style sheets within comments to make the
+documents backward compatible is likely to not work as expected in XML-based
+implementations.
+
+
C.5 Line Breaks within Attribute Values
+
Avoid line breaks and multiple whitespace characters within
+attribute values. These are handled inconsistently by user
+agents.
+
+
C.6 Isindex
+
Don't include more than one isindex element in
+the document head. The isindex element
+is deprecated in favor of the input element.
+
+
C.7 The lang and xml:lang Attributes
+
Use both the lang and xml:lang
+attributes when specifying the language of an element. The value
+of the xml:lang attribute takes precedence.
+
+
C.8 Fragment Identifiers
+
In XML, URIs [RFC2396] that end with fragment identifiers of the form
+"#foo" do not refer to elements with an attribute
+name="foo"; rather, they refer to elements with an
+attribute defined to be of type ID, e.g., the
+id attribute in HTML 4.0. Many existing HTML clients don't
+support the use of ID-type attributes in this way,
+so identical values may be supplied for both of these attributes to ensure
+maximum forward and backward compatibility (e.g., <a id="foo" name="foo">...</a>).
+
+
Further, since the set of
+legal values for attributes of type ID is much smaller than
+for those of type CDATA, the type of the name
+attribute has been changed to NMTOKEN. This attribute is
+constrained such that it can only have the same values as type
+ID, or as the Name production in XML 1.0 Section
+2.5, production 5. Unfortunately, this constraint cannot be expressed in the
+XHTML 1.0 DTDs. Because of this change, care must be taken when
+converting existing HTML documents. The values of these attributes
+must be unique within the document, valid, and any references to these
+fragment identifiers (both
+internal and external) must be updated should the values be changed during
+conversion.
+
Finally, note that XHTML 1.0 has deprecated the
+name attribute of the a, applet, frame, iframe, img, and map
+elements, and it will be
+removed from XHTML in subsequent versions.
+
+
C.9 Character Encoding
+
To specify a character encoding in the document, use both the
+encoding attribute specification on the xml declaration (e.g.
+<?xml version="1.0"
+encoding="EUC-JP"?>) and a meta http-equiv statement
+(e.g. <meta http-equiv="Content-type"
+content='text/html; charset="EUC-JP"' />). The
+value of the encoding attribute of the xml processing instruction
+takes precedence.
+
+
C.10 Boolean Attributes
+
Some HTML user agents are unable to interpret boolean
+attributes when these appear in their full (non-minimized) form,
+as required by XML 1.0. Note this problem doesn't effect user
+agents compliant with HTML 4.0. The following attributes are
+involved: compact, nowrap,
+ismap, declare, noshade,
+checked, disabled, readonly,
+multiple, selected,
+noresize, defer.
+
+
C.11 Document Object Model and XHTML
+
+The Document Object Model level 1 Recommendation [DOM]
+defines document object model interfaces for XML and HTML 4.0. The HTML 4.0
+document object model specifies that HTML element and attribute names are
+returned in upper-case. The XML document object model specifies that
+element and attribute names are returned in the case they are specified. In
+XHTML 1.0, elements and attributes are specified in lower-case. This apparent difference can be
+addressed in two ways:
+
+
+
Applications that access XHTML documents served as Internet media type
+text/html
+via the DOM can use the HTML DOM,
+and can rely upon element and attribute names being returned in
+upper-case from those interfaces.
+
Applications that access XHTML documents served as Internet media types
+text/xml or application/xml
+can also use the XML DOM. Elements and attributes will be returned in lower-case.
+Also, some XHTML elements may or may
+not appear
+in the object tree because they are optional in the content model
+(e.g. the tbody element within
+table). This occurs because in HTML 4.0 some elements were
+permitted to be minimized such that their start and end tags are both omitted
+(an SGML feature).
+This is not possible in XML. Rather than require document authors to insert
+extraneous elements, XHTML has made the elements optional.
+Applications need to adapt to this
+accordingly.
+
+
+
C.12 Using Ampersands in Attribute Values
+
+When an attribute value contains an ampersand, it must be expressed as a character
+entity reference
+(e.g. "&"). For example, when the
+href attribute
+of the a element refers to a
+CGI script that takes parameters, it must be expressed as
+http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user
+rather than as
+http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.
+
+
+
C.13 Cascading Style Sheets (CSS) and XHTML
+
+
The Cascading Style Sheets level 2 Recommendation [CSS2] defines style
+properties which are applied to the parse tree of the HTML or XML
+document. Differences in parsing will produce different visual or
+aural results, depending on the selectors used. The following hints
+will reduce this effect for documents which are served without
+modification as both media types:
+
+
+
+CSS style sheets for XHTML should use lower case element and
+attribute names.
+
+
+
In tables, the tbody element will be inferred by the parser of an
+HTML user agent, but not by the parser of an XML user agent. Therefore
+you should always explicitely add a tbody element if it is referred to
+in a CSS selector.
+
+
Within the XHTML name space, user agents are expected to
+recognize the "id" attribute as an attribute of type ID.
+Therefore, style sheets should be able to continue using the
+shorthand "#" selector syntax even if the user agent does not read
+the DTD.
+
+
Within the XHTML name space, user agents are expected to
+recognize the "class" attribute. Therefore, style sheets should be
+able to continue using the shorthand "." selector syntax.
+
+
+CSS defines different conformance rules for HTML and XML documents;
+be aware that the HTML rules apply to XHTML documents delivered as
+HTML and the XML rules apply to XHTML documents delivered as XML.
This specification was written with the participation of the
+members of the W3C HTML working group:
+
+
+
Steven Pemberton, CWI (HTML Working Group Chair)
+Murray Altheim, Sun Microsystems
+Daniel Austin, CNET: The Computer Network
+Frank Boumphrey, HTML Writers Guild
+John Burger, Mitre
+Andrew W. Donoho, IBM
+Sam Dooley, IBM
+Klaus Hofrichter, GMD
+Philipp Hoschka, W3C
+Masayasu Ishikawa, W3C
+Warner ten Kate, Philips Electronics
+Peter King, Phone.com
+Paula Klante, JetForm
+Shin'ichi Matsui, W3C/Panasonic
+Shane McCarron, Applied Testing and Technology (The Open Group through August
+1999)
+Ann Navarro, HTML Writers Guild
+Zach Nies, Quark
+Dave Raggett, W3C/HP (W3C lead for HTML)
+Patrick Schmitz, Microsoft
+Sebastian Schnitzenbaumer, Stack Overflow
+Chris Wilson, Microsoft
+Ted Wugofski, Gateway 2000
+Dan Zigmond, WebTV Networks
"ISO/IEC 9945-1:1990 Information Technology - Portable
+Operating System Interface (POSIX) - Part 1: System Application
+Program Interface (API) [C Language]", Institute of Electrical
+and Electronics Engineers, Inc, 1990.
"Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14
+January 1999.
+XML namespaces provide a simple method for qualifying names used
+in XML documents by associating them with namespaces identified
+by URI.
+Available at:
+http://www.w3.org/TR/REC-xml-names
+
+ http://www.w3.org/XML/Group/1999/05/WD-xlink-current
+
+
+ http://www.w3.org/XML/Group/1999/05/WD-xlink-19990527
+ http://www.w3.org/XML/Group/1999/05/WD-xlink-19990505
+ http://www.w3.org/TR/1998/WD-xlink-19980303
+ http://www.w3.org/TR/WD-xml-link-970630
+
+
+
+
+
+ Steve DeRose
+ Inso Corp. and Brown University
+ Steven_DeRose@Brown.edu
+
+
+ David Orchard
+ IBM Corp.
+ dorchard@ca.ibm.com
+
+
+ Ben Trafford
+ Invited Expert
+ bent@exemplary.net
+
+
+
+
+
+
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR.
+
Note: Since working drafts are subject to frequent change, you are advised to reference the above URI, rather than the URIs for working drafts themselves. Some of the work remaining is described in .
+
This work is part of the W3C XML Activity (for current status, see http://www.w3.org/XML/Activity ). For information about the XPointer language which is expected to be used with XLink, see http://www.w3.org/TR/WD-xptr.
+
+
See http://www.w3.org/TR/NOTE-xlink-principles for additional background on the design principles informing XLink.
+
Also see http://www.w3.org/TR/NOTE-xlink-req/ for the XLink requirements that this document attempts to satisfy.
+
+
+
+
+
This specification defines constructs that may be inserted into XML DTDs, schemas and document instances to describe links between objects. It uses XML syntax to create structures that can describe the simple unidirectional hyperlinks of today's HTML as well as more sophisticated links.
+
+
+
+
Burlington, Seekonk, et al.: World-Wide Web Consortium, XML Working Group, 1998.
+
+
+
+
Created in electronic form.
+
+
+
+ English
+ Extended Backus-Naur Form (formal grammar)
+
+
+
+
+ 1997-01-15 : Skeleton draft by TB
+ 1997-01-24 : Fleshed out by sjd
+ 1997-04-08 : Substantive draft
+ 1997-06-30 : Public draft
+ 1997-08-01 : Public draft
+ 1997-08-05 : Prose/organization work by sjd
+ 1997-10-14: Conformance and design principles; a bit of cleanup by elm
+ 1997-11-07: Update for editorial issues per issues doc, by sjd.
+ 1997-12-01: Update for editorial issues per issues doc in preparation for F2F meeting, by sjd.
+ 1998-01-13: Editorial cleanup, addition of new design principles, by elm.
+ 1998-02-27: Splitting out of XLink and XPointer, by elm.
+ 1998-03-03: Moved most of the XPointer locator stuff here. elm
+ 1999-04-24: Editorial rewrites to represent new ideas on XLink, especially the inclusion of arcs. bent
+ 1999-05-05: Prose/organization work by dorchard. Moved much of the semantics section around, from: locators, link semantics, remote resource semantics, local resource semantics; to: resource semantics, locators, behavior semantics, link semantics, arc semantics
+ 1999-05-12: Prose/organization work. Re-organized some of the sections, removed XML constructs from the document, added descriptive prose, edited document text for clarity. Rewrote the link recognition section. bent
+ 1999-05-17: Further prose work. Added non-normative examples. Clarified arcs. bent
+ 1999-05-23: Edited for grammar and clarity. bent
+ 1999-05-27: Final once-over before sending to group. Fixed sjd's email address. bent
+
+
+
+
+
+
+ Introduction
+
This specification defines constructs that may be inserted into XML DTDs, schemas, and document instances to describe links between objects. A link, as the term is used here, is an explicit relationship between two or more data objects or portions of data objects. This specification is concerned with the syntax used to assert link existence and describe link characteristics. Implicit (unasserted) relationships, for example that of one word to the next or that of a word in a text to its entry in an on-line dictionary are obviously important, but outside its scope.
+
Links are asserted by elements contained in XML document instances. The simplest case is very like an HTML A link, and has these characteristics:
+
+
The link is expressed at one of its ends (similar to the A element in some document)
+
Users can only initiate travel from that end to the other
+
The link's effect on windows, frames, go-back lists, stylesheets in use, and so on is mainly determined by browsers, not by the link itself. For example, traveral of A links normally replaces the current view, perhaps with a user option to open a new window.
+
The link goes to only one destination (although a server may have great freedom in finding or dynamically creating that destination).
+
+
+
While this set of characteristics is already very powerful and obviously has proven itself highly useful and effective, each of these assumptions also limits the range of hypertext functionality. The linking model defined here provides ways to create links that go beyond each of these specific characteristics, thus providing features previously available mostly in dedicated hypermedia systems.
+
+
+
+ Origin and Goals
+
Following is a summary of the design principles governing XLink:
+
+
XLink must be straightforwardly usable over the Internet.
+
XLink must be usable by a wide variety of link usage domains and classes of linking application software.
+
XLink must support HTML 4.0 linking constructs.
+
The XLink expression language must be XML.
+
The XLink design must be formal, concise, and illustrative.
+
XLinks must be human-readable and human-writable.
+
XLinks may reside within or outside the documents in which the
+ participating resources reside.
+
XLink must represent the abstract structure and significance of links.
+
XLink must be feasible to implement.
+
XLink must be informed by knowledge of established hypermedia systems and standards.
+
+
+
+
+
+
+ Relationship to Existing Standards
+
Three standards have been especially influential:
+
+
HTML: Defines several SGML element types that represent links.
+
HyTime: Defines inline and out-of-line link structures and some semantic features, including traversal control and presentation of objects.
+
+
Text Encoding Initiative Guidelines (TEI P3): Provides structures for creating links, aggregate objects, and link collections out of them.
+
+
+
Many other linking systems have also informed this design, especially Dexter, FRESS, MicroCosm, and InterMedia.
+
+
+
+ Terminology
+
The following basic terms apply in this document.
+
+
+
+
A symbolic representation of traversal behavior in links, especially the direction, context and timing of traversal.
+
+
+
+
A representation of the relevant structure specified by the tags and attributes in an XML document, based on "groves" as defined in the ISO DSSSL standard.
+
+
+
+
Abstractly, a link which serves as one of its own resources. Concretely, a link where the content of the linking element serves as a participating resource.
+ HTML A, HyTime clink, and TEI XREF
+ are all inline links.
+
+
+
+
An explicit relationship between two or more data objects or portions of data objects.
+
+
+
+
An element that asserts the existence and describes the characteristics of a link.
+
+
+
+
The content of an inlinelinking element. Note that the content of the linking element could be explicitly pointed to by means of a regular locator in the same linking element, in which case the resource is considered remote, not local.
+
+
+
+
Data, provided as part of a link, which identifies a
+ resource.
+
+
+
+
A link whose traversal can be initiated from more than one of its participating resources. Note that being able to "go back" after following a one-directional link does not make the link multidirectional.
+
+
+
+
A link whose content does not serve as one of the link's participating resources . Such links presuppose a notion like extended link groups, which instruct application software where to look for links. Out-of-line links are generally required for supporting multidirectional traversal and for allowing read-only resources to have outgoing links.
+
+
+
In the context of link behavior, a parsed link is any link whose content is transcluded into the document where the link originated. The use of the term "parsed" directly refers to the concept in XML of a
+ parsed entity.
+
+
+
+
A resource that belongs to a link. All resources are potential contributors to a link; participating resources are the actual contributors to a particular link.
+
+
+
+
Any participating resource of a link that is pointed to with a locator.
+
+
+
+
In the abstract sense, an addressable unit of information or service that is participating in a link. Examples include files, images, documents, programs, and query results. Concretely, anything reachable by the use of a locator in some linking element. Note that this term and its definition are taken from the basic specifications governing the World Wide Web.
+
+
+
+
+
A portion of a resource, pointed to as the precise destination of a link. As one example, a link might specify that an entire document be retrieved and displayed, but that some specific part(s) of it is the specific linked data, to be treated in an application-appropriate manner such as indication by highlighting, scrolling, etc.
+
+
+
+
The action of using a link; that is, of accessing a resource. Traversal may be initiated by a user action (for example, clicking on the displayed content of a linking element) or occur under program control.
+
+
+
+
+
+
+ Notation
+
The formal grammar for locators is given using a simple Extended Backus-Naur Form (EBNF) location, as described in the XML specification.
+
+
+
+
+
+ Locator Syntax
+
The locator for a resource is typically provided by means of a Uniform Resource Identifier, or URI. XPointers can be used in conjunction with the URI structure, as fragment identifiers, to specify a more precise sub-resource.
+
+
A locator generally contains a URI, as described in IETF RFCs and . As these RFCs state, the URI may include a trailing query (marked by a leading "?"), and be followed by a "#" and a fragment identifier, with the query interpreted by the host providing the indicated resource, and the interpretation of the fragment identifier dependent on the data type of the indicated resource.
+
+
In order to locate XML documents and portions of documents, a locator value may contain either a URI or a fragment identifier, or both. Any fragment identifier for pointing into XML must be an XPointer.
+
Special syntax may be used to request the use of particular processing models in accessing the locator's resource. This is designed to reflect the realities of network operation, where it may or may not be desirable to exercise fine control over the distribution of work between local and remote processors.
+
+ Locator
+
+ Locator
+ URI
+ | Connector (XPointer | Name)
+ | URIConnector (XPointer | Name)
+
+
+ Connector'#' | '|'
+
+
+ URIURIchar*
+
+
+
+
In this discussion, the term designated resource refers to the resource which an entire locator serves to locate. The following rules apply:
+
+
+
The URI, if provided, locates a resource called the containing resource.
+
+
+
If the URI is not provided, the containing resource is considered to be the document in which the linking element is contained.
+
+
+
If an XPointer is provided, the designated resource is a sub-resource
+ of the containing resource; otherwise the designated resource is the
+ containing resource.
+
+
+
+
If the Connector is followed directly by a Name, the Name is shorthand for the XPointer"id(Name)"; that is, the sub-resource is the element in the containing resource that has an XML ID attribute whose value matches the Name. This shorthand is to encourage use of the robust id addressing mode.
+
+
+
+
If the connector is "#", this signals an intent that the containing resource is to be fetched as a whole from the host that provides it, and that the XPointer processing to extract the sub-resource
+ is to be performed on the client, that is to say on the same system where the linking element is recognized and processed.
+
+
+
If the connector is "|", no intent is signaled as to what processing model is to be used to go about accessing the designated resource.
+
+
+
+
Note that the definition of a URI includes an optional query component.
+
In the case where the URI contains a query (to be interpreted by the server), information providers and authors of server software are urged to use queries as follows:
+
+ Query
+
+ Query'XML-XPTR=' ( XPointer | Name)
+
+
+
+
+
+
+
+ Link Recognition
+
The existence of a link is asserted by a linking element. Linking elements must be recognized reliably by application software in order to provide appropriate display and behavior. There are several ways link recognition could be accomplished: for example, reserving element type names, reserving attributes names, leaving the matter of recognition entirely up to stylesheets and application software, or using the XLink namespace to specify element names and attribute names that would be recognized by namespace and XLink-aware processors. Using element and attribute names within the XLink namespace provides a balance between giving users control of their own markup language design and keeping the identification of linking elements simple and unambiguous.
+
The two approaches to identifying linking elements are relatively simple to implement. For example, here's how the HTML A element would be declared using attributes within the XLink namespace, and then how an element within the XLink namespace might do the same:
+ <A xlink:type="simple" xlink:href="http://www.w3.org/TR/wd-xlink/"
+xlink:title="The Xlink Working Draft">The XLink Working Draft.</A>
+ <xlink:simple href="http://www.w3.org/TR/wd-xlink/"
+title="The XLink Working Draft">The XLink Working Draft</xlink:simple>
+ Any arbitrary element can be made into an XLink by using the xlink:type attribute. And, of course, the explicit XLink elements may be used, as well. This document will go on to describe the linking attributes that are associated with linking elements. It may be assumed by the reader that these attributes would require the xlink namespace prefix if they existed within an arbitrary element, or that they may be used directly if they exist within an explicit Xlink element.
+
+
+
+
+
+ Linking Attributes
+
XLink has several attributes associated with the variety of links it may represent. These attributes define four main concepts: locators, arcs, behaviors, and semantics. Locators define where the actual resource is located. Arcs define the traversal of links. Where does the link come from? Where does it go to? All this information can be stored in the arc attributes. Behaviors define how the link is activated, and what the application should do with the resource being linked to. Semantics define useful information that the application may use, and enables the link for such specalized targets as constricted devices and accessibility software.
+
+
+ Locator Attributes
+
The only locator attribute at this time is href. This attribute must contain either a string in the form of a URI that defines the remote resource being linked to, a string containing a fragment identifier that links to a local resource, or a string containing a URI with a fragment identifier concacenated onto it.
+
+
+
+ Arc Attributes
+
Arcs contain two attributes, from and to. The from attribute may contain a string containing the content of a role attribute from the resource being linked from. The purpose of the from attribute is to define where this link is being actuated from.
+
The to attribute may contain a string containing the content of a role attribute from the resource being linked to. The purpose of the to attribute is to define where this link traverses to.
+
The application may use this information in a number of ways, especially in a complex hypertext system, but it is mainly useful in providing context for application behavior.
+
+
+
+
+ Behavior Attributes
+
There are two attributes associated with behavior: show and actuate. The show attribute defines how the remote resource is to be revealed to the user. It has three options: new, parsed, and replace. The new option indicates that the remote resource should be shown in a new window (or other device context) without replacing the previous content. The parsed option, relating directly to the XML concept of a parsed entity, indicates that the content should be integrated into the document from which the link was actuated. The replace option is the one most commonly seen on the World Wide Web, where the document being linked from is entirely replaced by the object being linked to.
+
The actuate attribute defines how the link is initiated. It has two options: user and auto. The user option indicates that the link must be initiated by some sort of human-initiated selection, such as clicking on an HTML anchor. The auto option indicates that the link is automatically initiated when the application deems that the user has reached the link. It then follows the behavior set out in the show option.
+
+
+
+
+ Semantic Attributes
+
There are two attributes associated with semantics, role and title. The role attribute is a generic string used to describe the function of the link's content. For example, a poem might have a link with a role="stanza". The role is also used as an identifier for the from and to attributes of arcs.
+
The title attribute is designed to provide human-readable text describing the link. It is very useful for those who have text-based applications, whether that be due to a constricted device that cannot display the link's content, or if it's being read by an application to a visually-impaired user, or if it's being used to create a table of links. The title attribute contains a simple, descriptive string.
+
+
+
+
+ Linking Elements
+
There are several kinds of linking elements in XLink: simple links, locators, arcs, and extended links. These elements may be instantiated via element declarations from the XLink namespace, or they may be instantiated via attribute declarations from the XLink namespace. Both kinds of instantiation are described in the definition of each linking element.
+
The simple link is used to declare a link that approximates the functionality of the HTML A element. It has, however, a few added features to increase its value, including the potential declaration of semantics and behavior. The locator elements are used to define the resource being linked to. Some links may contain multiple locators, representing a choice of potential links to be traversed. The arcs are used to define the traversal semantics of the link. Finally, an extended linking element differs from a simple link in that it can connect any number of resources, not just one local resource (optionally) and one remote resource, and in that extended links are more often out-of-line than simple links.
+
+
+ Simple Links
+
Simple links can be used for purposes that approximate the functionality of a basic HTML A link, but they can also support a limited amount of additional functionality. Simple links have only one locator and thus, for convenience, combine the functions of a linking element and a locator into a single element. As a result of this combination, the simple linking element offers both a locator attribute and all the behavior and semantic attributes.
+
The following are two examples of linking elements, each showing all the possible attributes that can be associated with a simple link. Here is the explicit XLink simple linking element.
+ <!ELEMENT xlink:simple ANY>
+<!ATTLIST xlink:slink
+ href CDATA #REQUIRED
+ role CDATA #IMPLIED
+ title CDATA #IMPLIED
+ show (new|parsed|replace) "replace"
+ actuate (user|auto) "user"
+>
+ And here is how to make an arbitrary element into a simple link.
+ <!ELEMENT xlink:simple ANY>
+<!ATTLIST foo
+ xlink:type (simple|extended|locator|arc) #FIXED "simple"
+ xlink:href CDATA #REQUIRED
+ xlink:role CDATA #IMPLIED
+ xlink:title CDATA #IMPLIED
+ xlink:show (new|parsed|replace) "replace"
+ xlink:actuate (user|auto) "user"
+>
+ Here is how the first example might look in a document:
+<xlink:simple href="http://www.w3.org/TR/wd-xlink" role="working draft"
+ title="The XLink Working Draft" show="replace" actuate="user">
+The XLink Working Draft.</xlink:simple>
+<foo xlink:href="http://www.w3.org/TR/wd-xlink" xlink:role="working draft"
+ xlink:title="The XLink Working Draft" xlink:show="new" xlink:actuate="user">
+The XLink Working Draft.</foo>
+ Alternately, a simple link could be as terse as this:
+<foo xlink:href="#stanza1">The First Stanza.</foo>
+
+
+ There are no constraints on the contents of a simple linking element. In
+ the sample declaration above, it is given a content model of ANY
+ to illustrate that any content model or declared content is acceptable. In
+ a valid document, every element that is significant to XLink must still conform
+ to the constraints expressed in its governing DTD.
+
Note that it is meaningful to have an out-of-line simple link, although
+ such links are uncommon. They are called "one-ended" and are typically used
+ to associate discrete semantic properties with locations. The properties might
+ be expressed by attributes on the link, the link's element type name, or in
+ some other way, and are not considered full-fledged resources of the link.
+ Most out-of-line links are extended links, as these have a far wider range
+ of uses.
+
+
+
+Extended Links
+
An extended link differs from a simple link in that it can connect any number of resources, not just one local resource (optionally) and one remote resource, and in that extended links are more often out-of-line than simple links.
+
These additional capabilities of extended links are required for:
+
+
+
Enabling outgoing links in documents that cannot be modified to add an inline link
+
+
+
Creating links to and from resources in formats with no native support for embedded links (such as most multimedia formats)
+
+
+
Applying and filtering sets of relevant links on demand
+
+
Enabling other advanced hypermedia capabilities
+
+
+
Application software might be expected to provide traversal among all of a link's participating resources (subject to semantic constraints outside the scope of this specification) and to signal the fact that a given resource or sub-resource participates in one or more links when it is displayed (even though there is no markup at exactly that point to signal it).
+
A linking element for an extended link contains a series of child elements that serve as locators and arcs. Because an extended link can have more than one remote resource, it separates out linking itself from the mechanisms used to locate each resource (whereas a simple link combines the two).
+
The xlink:type attribute value for an extended link must be extended, if the link is being instantiated on an arbitrary element. Note that extended links introduce variants of the show and actuate behavior attributes. These attributes, the showdefault and actuatedefault define the same behavior as their counterparts. However, in this case, they are considered to define the default behavior for all the linking elements that they contain.
+
However, when a linking element within an extended link has a show or actuate attribute of its own, that attribute overrides the defaults set on the extended linking element.
+
The extended linking element itself retains those attributes relevant to the link as a whole, and to its local resource if any. Following are two sample declaration for an extended link. The first is an example of the explicit XLink extended link:
+
+<!ELEMENT xlink:extended ((xlink:arc | xlink:locator)*)>
+<!ATTLIST xlink:extended
+ role CDATA #IMPLIED
+ title CDATA #IMPLIED
+ showdefault (new|parsed|replace) #IMPLIED
+ actuatedefault (user|auto) #IMPLIED >
+
+ The second is an example of an arbitrary element being used an extended link:
+
+<!ELEMENT foo ((xlink:arc | xlink:locator)*)>
+<!ATTLIST foo
+ xlink:type (simple|extended|locator|arc) #FIXED "extended"
+ xlink:role CDATA #IMPLIED
+ xlink:title CDATA #IMPLIED
+ xlink:showdefault (new|parsed|replace) #IMPLIED
+ xlink:actuatedefault (user|auto) #IMPLIED >
+
+ The following two examples demonstrate how each of the above might appear within a document instance. Note that the content of these examples would be other elements. For brevity's sake, they've been left blank. The first example shows how the link might appear, using an explicit XLink extended link:
+
+<xlink:extended role="address book" title="Ben's Address Book" showdefault="replace" actuatedefault="user"> ... </xlink:extended>
+
+ And the second shows how the link might appear, using an arbitrary element:
+
+<foo xlink:type="extended" xlink:role="address book" xlink:title="Ben's Address Book" xlink:showdefault="replace" xlink:actuatedefault="user"> ... </foo>
+
+
+
+
+
+ Arc Elements
+
An arc is contained within an extended link for the purpose of defining traversal behavior. More than one arc may be associated with a link. Otherwise, arc elements function exactly as the arc attributes might lead on to expect.
+
+
+
+
+
+Conformance
+
An element conforms to XLink if:
+
The element has an xml:link attribute whose value is
+one of the attribute values prescribed by this specification, and
+
the element and all of its attributes and content adhere to the
+syntactic
+requirements imposed by the chosen xml:link attribute value,
+as prescribed in this specification.
+
+
Note that conformance is assessed at the level of individual elements,
+rather than whole XML documents, because XLink and non-XLink linking mechanisms
+may be used side by side in any one document.
+
An application conforms to XLink if it interprets XLink-conforming elements
+according to all required semantics prescribed by this specification and,
+for any optional semantics it chooses to support, supports them in the way
+prescribed.
+
+
+
+Unfinished Work
+
+Structured Titles
+
The simple title mechanism described in this draft is insufficient to cope
+with internationalization or the use of multimedia in link titles. A future
+version will provide a mechanism for the use of structured link titles.
+
+
+
+References
+
+Eve Maler and Steve DeRose, editors.
+XML Pointer Language (XPointer) V1.0. ArborText, Inso, and Brown
+University. Burlington, Seekonk, et al.: World Wide Web Consortium, 1998.
+(See http://www.w3.org/TR/WD-xptr
+ .)
+ISO (International Organization for
+Standardization). ISO/IEC 10744-1992 (E). Information technology
+- Hypermedia/Time-based Structuring Language (HyTime). [Geneva]:
+International Organization for Standardization, 1992. Extended
+Facilities
+Annex. [Geneva]: International Organization for Standardization,
+1996. (See http://www.ornl.go
+v/sgml/wg8/hytime/html/is10744r.html ).
+IETF (Internet Engineering Task
+Force).
+RFC 1738: Uniform Resource Locators. 1991. (See
+http://www.w3.org/Addressing/rfc1738.txt).
+IETF (Internet Engineering Task
+Force).
+RFC 1808: Relative Uniform Resource Locators. 1995. (See http://www.w3.org/Addressing/rfc
+1808.txt ).
+C. M. Sperberg-McQueen and Lou Burnard, editors.
+
+Guidelines for Electronic Text Encoding and Interchange. Association
+for Computers and the Humanities (ACH), Association for Computational
+Linguistics
+(ACL), and Association for Literary and Linguistic Computing (ALLC). Chicago,
+Oxford: Text Encoding Initiative, 1994.
+]Steven J. DeRose and David G. Durand. 1995. "The
+TEI Hypertext Guidelines." In Computing and the Humanities
+29(3).
+Reprinted in Text Encoding Initiative: Background and
+Context,
+ed. Nancy Ide and Jean ronis , ISBN 0-7923-3704-2.
+
+
+
diff --git a/corp-xml/b719798fdee8cda075cf55e382b4253b b/corp-xml/b719798fdee8cda075cf55e382b4253b
new file mode 100644
index 0000000..bfab69a
--- /dev/null
+++ b/corp-xml/b719798fdee8cda075cf55e382b4253b
@@ -0,0 +1,14 @@
+
+
+
+
+
+
+
+]>
+
+
+
+
diff --git a/corp-xml/bf43083f7b6316fee792fa012473b878 b/corp-xml/bf43083f7b6316fee792fa012473b878
new file mode 100644
index 0000000..057c926
--- /dev/null
+++ b/corp-xml/bf43083f7b6316fee792fa012473b878
@@ -0,0 +1,5 @@
+
+
+
+ &entity;
+
diff --git a/corp-xml/c4a8599139a93406914c09772bbe08e2 b/corp-xml/c4a8599139a93406914c09772bbe08e2
new file mode 100644
index 0000000..19a95a0
--- /dev/null
+++ b/corp-xml/c4a8599139a93406914c09772bbe08e2
@@ -0,0 +1,2 @@
+
+
diff --git a/corp-xml/d07e218f94d8eb5b4bbbe1758c542239 b/corp-xml/d07e218f94d8eb5b4bbbe1758c542239
new file mode 100644
index 0000000..c7c2b0a
--- /dev/null
+++ b/corp-xml/d07e218f94d8eb5b4bbbe1758c542239
@@ -0,0 +1,8 @@
+
+' >
+' >
+' >
+%defroot; %defmiddle; %deftest;
+]>
+sample
diff --git a/corp-xml/d15ca3e362f972cc14d68d09b4ba22c0 b/corp-xml/d15ca3e362f972cc14d68d09b4ba22c0
new file mode 100644
index 0000000..de066f9
--- /dev/null
+++ b/corp-xml/d15ca3e362f972cc14d68d09b4ba22c0
@@ -0,0 +1,12 @@
+
+
+
+
+]>
+
+
+
+
+
+
diff --git a/corp-xml/dc226500c3f318900b5d0a1c87c8e690 b/corp-xml/dc226500c3f318900b5d0a1c87c8e690
new file mode 100644
index 0000000..22d8ed8
--- /dev/null
+++ b/corp-xml/dc226500c3f318900b5d0a1c87c8e690
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+]>
+
+ Some text.
+
+ Some text.
+
+ Some text.
+
diff --git a/corp-xml/e516671bcd671eac84c8ee04fbdf36b5 b/corp-xml/e516671bcd671eac84c8ee04fbdf36b5
new file mode 100644
index 0000000..2d27b73
--- /dev/null
+++ b/corp-xml/e516671bcd671eac84c8ee04fbdf36b5
@@ -0,0 +1,10 @@
+
+
+
+
+]>
+
+
+ ⌖
+
diff --git a/corp-xml/ebcbfe23e11bea698f7597690555fe2d b/corp-xml/ebcbfe23e11bea698f7597690555fe2d
new file mode 100644
index 0000000..117c30f
--- /dev/null
+++ b/corp-xml/ebcbfe23e11bea698f7597690555fe2d
@@ -0,0 +1,9 @@
+
+
+
+
+]>
+
+
diff --git a/corp-xml/f2ab62e2eca7a5a2c7ec2db3a7f7c245 b/corp-xml/f2ab62e2eca7a5a2c7ec2db3a7f7c245
new file mode 100644
index 0000000..cc3fb31
--- /dev/null
+++ b/corp-xml/f2ab62e2eca7a5a2c7ec2db3a7f7c245
@@ -0,0 +1,2 @@
+
+&peInCdata;
diff --git a/corp-xml/f6e9f489fa2dd1c8dc017e073dca5487 b/corp-xml/f6e9f489fa2dd1c8dc017e073dca5487
new file mode 100644
index 0000000..5b4a77a
--- /dev/null
+++ b/corp-xml/f6e9f489fa2dd1c8dc017e073dca5487
@@ -0,0 +1,14 @@
+
+
+
+
+
+">
+]>
+
+
+ &dest;
+
+
+
diff --git a/xml.py b/xml.py
new file mode 100644
index 0000000..26e6f61
--- /dev/null
+++ b/xml.py
@@ -0,0 +1,7 @@
+import xml.etree.ElementTree as ET
+
+def FuzzerRunOne(FuzzerInput):
+ try:
+ tree = ET.fromstring(FuzzerInput.decode("utf-8", "replace"))
+ except ET.ParseError:
+ pass