Introduction
Extensible
Markup Language, abbreviated XML, describes a class of data objects called XML
documents and partially describes the behavior of computer programs which
process them. XML is an application profile or restricted form of SGML, the
Standard Generalized Markup Language [ISO 8879]. By construction, XML documents
are con-forming SGML documents.
XML
documents are made up of storage units called entities, which contain either
parsed or unparsed data. Parsed data is made up of characters, some of which
form character data, and some of which form markup. Markup encodes a
description of the document’s storage layout and logical structure. XML provides
a mechanism to impose constraints on the storage layout and logical structure.
[Definition: A software
module called an XML processor is used to read XML docu-ments and provide
access to their content and structure.] [Definition: It is assumed that an XML
processor is doing its work on behalf of another module, called the
application.] This specification describes the required behavior of an XML
processor in terms of how it must read XML data and the information it must
provide to the application.
1
Origin and Goals
XML was developed by an XML
Working Group (originally known as the SGML Editorial Review Board) formed
under the auspices of the World Wide Web Consortium (W3C) in 1996. It was
chaired by Jon Bosak of Sun Microsystems with the active partic-ipation of an
XML Special Interest Group (previously known as the SGML Working Group) also
organized by the W3C. The membership of the XML Working Group is given in an
appendix. Dan Connolly served as the WG’s contact with the W3C.
The design goals for XML are:
XML shall be straightforwardly usable over the Internet.
XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the
absolute minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness in XML markup is of minimal importance.
This specification, together
with associated standards (Unicode and ISO/IEC 10646 for characters, Internet
RFC 1766 for language identification tags, ISO 639 for language name codes, and
ISO 3166 for country name codes), provides all the information neces-sary to
understand XML Version 1.0 and construct computer programs to process it.
This version of the XML
specification may be distributed freely, as long as all text and legal notices
remain intact.
2
Terminology
The terminology used to
describe XML documents is defined in the body of this specifi-cation. The terms
defined in the following list are used in building those definitions and in
describing the actions of an XML processor:
may
[Definition: Conforming
documents and XML processors are permitted to but need not behave as
described.]
must
[Definition:
Conforming documents and XML processors are required to behave as described;
otherwise they are in error.]
error
[Definition:
A violation of the rules of this specification; results are undefined.
Conforming software may detect and report an error and may recover from it.]
fatal error
[Definition:
An error which a conforming XML processor must detect and report to the
application. After encountering a fatal error, the processor may continue
processing the data to search for further errors and may report such errors to
the application. In order to support correction of errors, the processor may
make unprocessed data from the docu-ment (with intermingled character data and
markup) available to the application. Once a fatal error is detected, however,
the processor must not continue normal processing (i.e., it must not continue
to pass character data and information about the document’s logical structure
to the application in the normal way).]
at user option
[Definition:
Conforming software may or must (depending on the modal verb in the sen-tence)
behave as described; if it does, it must provide users a means to enable or
disable the behavior described.]
validity constraint
[Definition:
A rule which applies to all valid XML documents. Violations of validity
con-straints are errors; they must, at user option, be reported by validating
XML processors.]
well-formedness constraint
[Definition:
A rule which applies to all well-formed XML documents. Violations of
well-formedness constraints are fatal errors.]
match
[Definition:
(Of strings or names:) Two strings or names being compared must be identi-cal.
Characters with multiple possible representations in ISO/IEC 10646 (e.g.
characters with both precomposed and base+diacritic forms) match only if they
have the same repre-sentation in both strings. No case folding is performed.
(Of strings and rules in the gram-mar:) A string matches a grammatical
production if it belongs to the language generated by that production. (Of
content and content models:) An element matches its declaration when it
conforms in the fashion described in the constraint [VC: Element Valid].]
for compatibility
[Definition: Marks a sentence
describing a feature of XML included solely to ensure that XML remains
compatible with SGML.]
for interoperability
[Definition: Marks a sentence
describing a non-binding recommendation included to increase the chances that
XML documents can be processed by the existing installed base of SGML
processors which predate the WebSGML Adaptations Annex to ISO 8879.]
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.