Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols

Many Internet protocol designers are considering using XML and XML fragments within the context of existing and new Internet protocols. This document is intended as a guide to XML usage and as IETF policy for standards track documents. Experienced XML practitioners will likely already be familiar with the background material here, but the guidelines are intended to be appropriate for those readers as well.¶

This document is intended to give guidelines for the use of XML content within a larger protocol. The goal is not to suggest that XML is the "best" or "preferred" way to represent data; rather, the goal is to lay out the context for the use of XML within a protocol once other factors point to XML as a possible data representation solution. The Common Name Resolution Protocol (CNRP, [24]) is an example of a protocol that would be addressed by these guidelines if it were being newly defined. This document does not address the use of protocols like SMTP or HTTP to send XML documents as ordinary email or web content.¶

There are a number of protocol frameworks already in use or under development which focus entirely on "XML protocol" -- the exclusive use of XML as the data representation in the protocol. For example, the World Wide Web Consortium (W3C) is developing an XML Protocol framework based on SOAP ([45] and [46]). The applicability of such protocols is not part of the scope of this document.¶

In addition, there are higher-level representation frameworks, based on XML, that have been designed as carriers of certain classes of information; for example, the Resource Description Framework (RDF, [38]) is an XML-based representation for logical assertions. This document does not provide guidelines for the use of such frameworks.¶

XML 1.0 was originally published as a W3C recommendation in February 1998 [35], and was revised in a 2nd edition [8] in October 2000. Several additional facilities have also been defined that layer on the base specification. Although these additions are designed to be consistent with XML 1.0, they have varying levels of stability, consensus, and implementation. Accordingly, this document identifies the major evolutionary features of XML and makes suggestions as to the circumstances in which each feature should be used.¶

There are many XML support groups, with some devoted to the entire XML industry, some devoted to developers, some devoted to the business applications of XML, and many, many groups devoted to the use of XML in a particular context.¶

It is beyond the scope of this document to provide a comprehensive list of referrals. Interested readers are directed to the three references above as starting points, as well as their favorite Internet search engine.¶

XML [8] is defined in terms of a concrete syntax: a sequence of characters, using the characters "<", "=", "&", etc. as delimiters. An instance is XML if and only if it is well-formed, i.e., all character and markup data conforms to the structural rules defined in section 2.1 of [8].¶

Character and markup data that is not well-formed is not XML; well-formedness is the basis for syntactic compatibility with XML. Without well-formedness, all of the advantages of using XML disappear. For this reason, it is recommended that protocol specifications explicitly require XML well-formedness ("MUST be well-formed").¶

The IETF has a long-standing tradition of "be liberal in what you accept" that might seem to be at odds with this recommendation. Given that XML requires well-formedness, conformant XML parsers are intolerant of well-formedness errors. When specifying the handing of erroneous XML protocol elements, a protocol design must never recommend attempting to partially interpret non-well-formed instances of an element which is required to be XML. Reasonable behaviors in such a scenario could include attempting retransmission or aborting an in-progress session.¶

In addition to the concrete syntax of XML, there is an abstract model of XML content known as the "Information Set" (infoset) [37]. One might think of an XML parser as consuming the concrete syntax and producing an XML Information Set for further processing.¶

In typical use of XML, the definition of allowable XML documents is often defined in terms of the Information Set of the XML and not the concrete syntax. The notion is that any syntactic representation which yielded the same information set would be treated equivalently.¶

It some cases, protocols have been defined solely in terms of the XML Information Set, or by allowing other concrete syntax representations. However, since the context of XML embedded within other Internet protocols requires an unambiguous definition of the concrete syntax, defining an XML protocol element in terms of its XML Information Set alone and allowing other concrete syntax representations is out of scope for this document.¶

In some circumstances a protocol designer may be tempted to define an XML-based protocol element as "XML", but at the same time imposing additional restrictions beyond those imposed by the XML recommendation itself -- for example, restricting the document character encoding, or avoiding CDATA sections, character entity references, imposing additional restrictions on use of white space, etc. The general category of restrictions addressed by this section are ones that would allow some but not other of the set of syntactic representations which have the same canonical representation according to canonical XML described in RFC 3076 [6].¶

Making these kinds of restrictions in a protocol definition may have the disadvantage that an implementer of the protocol may not be able to use an otherwise conforming XML processor to parse the XML-based protocol elements. In some cases, the motivation for subsetting XML is to allow implementers to build special-purpose processors that are lighter weight than a full-scale conforming XML processor. There are a number of good, conforming XML parsers that are small, fast, and free, while special-purpose processors have frequently been known to fail to handle some cases of legal XML syntax.¶

In general, such syntactic restrictions should be avoided. In circumstances where restrictions on the variability of the syntactic representation of XML is necessary for one reason or another, designers should consider using "Canonical XML" [6] as the definition of the protocol element, since all such variability has been removed. Some specific issues are discussed in Section 4.4, Section 4.13, and Section 5.1 below.¶

An XML declaration (defined in section 2.8 of [8]) is a small header at the beginning of an XML data stream that indicates the XML version and the character encoding used. For example,¶

<?xml version="1.0" encoding="UTF-8"?>¶

specifies the use of XML version 1 and UTF-8 character encoding.¶

In some uses of XML as an embedded protocol element, the XML used is a small fragment in a larger context, where the XML version is fixed at "1.0" and the character encoding is known to be "UTF-8". In those cases, an XML declaration might add extra overhead. In cases where the XML is a larger component which may find its way alone as an external entity body (transported as a MIME message, for example), the XML declaration is an important marker and is useful for reliability and extensibility. The XML declaration is also an important marker for character set/encoding (see Section 5.1), if any encoding other than UTF-8 or UTF-16 is used. Note that in the case of UTF-16, XML requires that the entity starts with a Byte Order Mark (BOM), which is not part of the character data. Note that the XML Declaration itself is not part of the XML document's Information Set.¶

Protocol specifications must be clear about use of XML declarations. XML [8] notes that "XML documents should begin with an XML declaration which specifies the version of XML being used." In general, an XML declaration should be encouraged ("SHOULD be present") and must always be allowed ("MAY be sent"). An XML declaration should be required in cases where, if allowed, the character encoding is anything other than UTF-8 or UTF-16.¶

<?rfc toc="yes"?>¶

As described in section 2.6 of [8], processing instructions are not part of the document's character data, but must be passed through to the application. As a consequence, it is recommended that processing instructions be ignored when encountered in normal protocol processing. It is thus also recommended that processing instructions not be used to define normative protocol data structures or extensions for the following reasons: ¶

• Processing instructions are not namespace aware; there is no way to qualify a processing instruction target with a namespace.
• Processing instruction use can not be constrained by most schema languages,
• Character references are not recognized within a processing instruction.
• Processing instructions don't have any XML-defined structure beyond the division between the target and everything else. This means that applications typically have to parse the content of the processing instruction in a system-dependent way; if the content was provided within an element instead, the structure could be expressed in the XML and the parsing could be done by the XML parser.

<!-- This is a example comment. -->¶

XML comments can be ignored by conformant processors. As a consequence, it is strongly recommended that comments not be used to define normative protocol data structures or extensions. It is thus also strongly recommended that comments be ignored if encountered in normal protocol processing.¶

One important value of XML is that there are formal mechanisms for defining structural and data content constraints; these constrain the identity of elements or attributes or the values contained within them. There is more than one such formalism: ¶

• A "Document Type Definition" (DTD) is defined in section 2.8 of [8]; the concept came from a similar mechanism for SGML. There is significant experience with using DTDs, including in IETF protocols.
• XML Schema (defined in [41] and [42]) provides additional features to allow a tighter and more precise specification of allowable protocol syntax and data type specifications.
• There are also a number of other mechanisms for describing XML instance validity; these include, for example, Schematron [49] and RELAX NG [48]. Part 2 of the ISO/IEC Document Schema Definition Language (DSDL, [32]) standard is based on RELAX NG.

There is ongoing discussion (and controversy) within the XML community on the use and applicability of various validity constraint mechanisms. The choice of tool depends on the needs for extensibility or for a formal language and mechanism for constraining permissible values and validating adherence to the constraints.¶

There are cases where protocols have defined validity using one or another validity mechanism, but the protocol definitions have not insisted that all corresponding protocol elements be "valid". The decision depends in part on the design for protocol extensibility. Each formalism has different ways of allowing for future extensions; in addition, a protocol design may have its own versioning mechanism, way of updating the schema, or pointing to a new one. For example, the use of XML namespaces (Section 4.9) with XML Schema allows other kinds of extensibility without compromising schema validity.¶

No matter what formalism is chosen, there are usually additional syntactic constraints, and inevitably additional semantic constraints, on the validity of XML elements that cannot be expressed in the formalism.¶

This document makes the following recommendations for the definition of protocols using XML: ¶

• Protocols should use an appropriate formalism for defining validity of XML protocol elements.
• Protocols may or may not insist that all corresponding protocol elements be valid, according to the validity mechanism chosen; in either case, the extensibility design should be clear. What happens if the data is not valid?
• As described in Section 3 there is no standard mechanism in XML for indicating whether or not new extensions are mandatory to recognize. XML-based protocol specifications should thus explicitly describe extension mechanisms and requirements to recognize or ignore extensions.

An idealized model for XML processing might first check for well-formedness; if OK, apply the primary formalism and, if the instances "passes", apply the other constraints so that the entire set (or as much as is machine processable) can be checked at the same time.¶

However, it is reasonable to allow conforming implementations to avoid doing validation at run-time and rely instead on ad-hoc code to avoid the higher expense, for example, of schema validation, especially given that there will likely be additional hand-crafted semantic validation.¶

While the definition of an XML protocol element using a validity formalism is useful, it is not sufficient. XML by itself does not supply semantics. Any document defining a protocol element with XML MUST also have sufficient prose in the document describing the semantics of whatever XML the document has elected to define.¶

XML namespaces, defined in [9], provide a means of assigning markup to a specific vocabulary. If two elements or attributes from different vocabularies have the same name, they can be distinguished unambiguously if they belong to different namespaces. Additionally, namespaces provide significant support for protocol extensibility as they can be defined, reused, and processed dynamically.¶

Markup vocabulary collisions are very possible when namespaces are not used to separate and uniquely identify vocabularies. Protocol definitions should use existing XML namespaces where appropriate. When a new namespace is needed, the "namespace name" is a URI that is used to identify the namespace; it's also useful for that URI to point to a description of the namespace. Typically (and recommended practice in W3C) is to assign namespace names using persistent http URIs.¶

In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. In lieu of such, other permanent URIs can be used, e.g., URNs in the IETF URN namespace (see [11] and [12]). Although there are instances of IETF specifications creating new URI schemes to define XML namespaces, this practice is strongly discouraged.¶

XML provides much flexibility in allowing a designer to use either elements, attributes, or element content to carry data. This section gives a flavor of the design considerations; there is much written about this in the XML literature. Consistent use of elements, attributes, and values is an important characteristic of a sound design.¶

Attributes are generally intended to contain meta-data that describes the element, and as such they are subject to the following restrictions: ¶

• Attributes are unordered,
• There can be no more than one instance of a given attribute within a given element, though an attribute may contain several values separated by white space ([8], section 2.3 and 3.3.1),
• Attribute values can have no internal XML markup for providing internal structure, and
• Attribute values are normalized ([8], section 3.3) before processing

Consider the following example that describes an IP address using an attribute to describe the address value: ¶

  <address addrType="ipv4">10.1.2.3</address>
            

One might encode the same information using an <addrType> element instead of an "addrType" attribute: ¶

  <address>
    <addrType>ipv4</addrType>
    <value>10.1.2.3</value>
  </address>
            

Another way of encoding the same information would be to use markup for the "addrType": ¶

  <address>
    <addrType><ipv4/></addrType>
    <value>10.1.2.3</value>
  </address>
            

Choosing between these designs involves tradeoffs concerning, among other considerations, the likely extensibility patterns and the ability of the formalism to constrain the values appropriately. In the first example, the attribute can be thought of as meta-data to the element which it modifies, and provides for a kind of "element extensibility". The third example allows for a different kind of extensibility: the "ipv4" space can be extended using other namespaces, and the <ipv4> element can include additional markup.¶

Many protocols include parameters that are selected from an enumerated set of values. Such enumerated values can be encoded as elements, attributes, or strings within element values. Any protocol design should consider how the set of enumerated values is to be extended: by revising the protocol, by including different values in different XML namespaces, or by establishing an IANA registry (as per RFC 2434 [18]). In addition, a common practice in XML is to use a URI as an XML attribute value or content.¶

Languages that describe syntactic validity (including XML Schema and DTDs) often provide a mechanism for specifying "default" values for an attribute. If an element does not specify a value for the attribute, then the "default" value is used. The use of default values for attributes is discouraged by this document. Although the use of this feature can reduce both the size and clutter of XML documents, it has a negative impact on software which doesn't know the document's validity constraints (e.g., for packet tracing or digital signature).¶

XML is defined as a character stream rather than a stream of octets. There is no way to embed raw binary data directly within an XML data stream; all binary data must be encoded as characters. There are a number of possible encodings; for example, XML Schema [42] defines encodings using decimal digits for integers, Base64 [15], or hexadecimal digits. In addition, binary data might be transmitted using some other communication channel, and referenced within the XML data itself using a URI.¶

Protocols that need a container that can hold both structural data and large quantities of binary data should consider carefully whether XML is appropriate, since the Base64 and hex encodings are inefficient. Otherwise, protocols should use the mechanisms of XML Schema to represent binary data; the Base64 encoding is best for larger quantities of data.¶

XML does not allow "control" characters (0x00-0x1F) except for TAB (0x09), CR (0x0A), and LF (0x0D). They can not be specified even using character entity references. There is currently no common way of encoding them within what is otherwise ordinary text. This means that strings that might be considered "text" within an ABNF-defined protocol element may need to be treated as binary data within an XML representation, or some other encoding mechanism might need to be invented.¶

In some situations, it is possible to incrementally process an XML document as each tag is received; this is analogous to the process by which browsers incrementally render HTML pages as they are received. Note that incremental processing is difficult to implement if interspersed across multiple interactions. In other words, if a protocol requires incremental processing across both directions of a bidirectional stream, then it may place an unusual burden on protocol implementers.¶

In addition to its role as a validity mechanism, an XML DTD provides a facility for "entity declarations" ([8], section 4.2). An entity declaration defines, in the DTD, a kind of macro capability where an "entity reference" may be used to call up and include the content of the entity declaration.¶

This feature adds complexity to XML processing, and seems more appropriate for use of XML in document processing than in data representation. As such, this document recommends avoiding entity declarations in protocol specifications.¶

On the other hand, there are five standard entity references built into XML: "&amp;", "&lt;", "&gt;", "&apos;", and "&quot;". XML also has the ability to write character data using numeric entity references (using the Unicode [33] value for the character). Entity references are normally expanded before the XML Information Set is computed. Restricting the use of these entity references would introduce an additional syntactic restriction (see Section 4.3) unnecessarily; these entity references should be allowed.¶

When using XML in the context of a stateless protocol, be it the protocol itself (e.g., SOAP), or simply as content transferred by an existing protocol (e.g., XML/HTTP), care must be taken to not make the meaning of a message depend on information outside the message itself. XML provides external entities (see Section 4.13), which are an easy way to make the meaning of a message depend on something external. Using schema languages that can change the Infoset, like XML Schema, is another way.¶

The XML Base specification [36] defines an attribute "xml:base" in the XML namespace that is intended to affect the "base" to be used for relative URI processing described in RFC 2396 [17]. The facilities of xml:base for controlling URI processing may be useful to protocol designers, but if xml:base is allowed the interaction with any other protocol facilities for establishing URI context must be specified clearly. Note that use of relative URIs in namespace declarations has been deprecated by the W3C; some specific issues with relative URIs in namespace declarations and canonical XML can be found in section 1.3 of RFC 3076 [6].¶

Note also that, in many cases, the term "URI" and the syntactic use of URIs within XML allows non-ASCII characters within URIs. For example, the XML Schema "anyURI" datatype ([42] section 3.2.17) allows for direct encoding of characters outside of the US-ASCII range. Most current IETF protocols and specifications do not allow this syntax. Protocol specifications should be clear about the range of characters specified, e.g., by adding a restriction to the range of characters allowed in the anyURI schema datatype, or by specifying that characters outside the US-ASCII range should be escaped when passed to older protocols or APIs.¶

XML's prescribed white space handling behavior can be a source of confusion between protocol designers and implementers. In XML instances all white space is considered significant and is by default visible to processing applications. Consider this example from Section 4.10: ¶

  <address>
    <addrType><ipv4/></addrType>
    <value>10.1.2.3</value>
  </address>
            

This fragment contains an <address> element and two child elements. It also contains white space for pretty-printing purposes: ¶

• at least three line separators, which will be converted by the XML processor to newline (U+000A) characters (see section 2.11 of [8]), and
• one or more white space characters prefixing the <addrType> and <value> elements, which an XML processor will make visible to software reading the instance.

Implementers might safely assume that they can ignore the white space in the example above, but white space used for pretty-printing can be a source of confusion in other situations. Consider a minor change to the <value> element: ¶

  <value>
    10.1.2.3
  </value>
            

where white space is found on both sides of the IP address. XML processors treat the white space surrounding "10.1.2.3" as an integral part of the <value> element. A failure to recognize this behavior can lead to confusion and errors in both design and implementation.

All white space is considered significant in XML instances. As a consequence, it is recommended that protocol designers provide specific guidelines to address white space handling within protocols that use XML.¶

When XML is used in an IETF protocol there are multiple factors that might require IANA action, including: ¶

• XML media types. A piece of XML in a protocol element is sometimes intrinsically bound to the protocol context in which it appears, and in particular might be directly derived from and/or input to protocol state-machine implementations. In cases where the XML content has no relevant meaning outside it's original protocol context, there is no reason to register a MIME type. When it is possible that XML content can be interpreted outside of its original context (such as when that XML content is being stored in a file system or tunneled over another protocol), then a MIME type can be registered to specify the specific format for the data and to provide a hint as to how it might be processed.

  If MIME labeling is needed, then the advice of RFC 3023 [5] applies. In particular, if the XML represents a new language or document type, a new MIME media type should be registered for the reasons described in RFC 3023 sections 7 and A.1. In situations where XML is used to encode generic structured data (e.g., a document-oriented application that involves combining XML with a stylesheet), "application/xml" might be appropriate ("MAY be used"). The "text/xml" media type is not recommended ("SHOULD NOT be used") because of issues involving display behavior and default charsets.

• URI registration. There is an ongoing effort ([11], [12]) to create a URN namespace explicitly for defining URIs for namespace names and other URI-designated protocol elements for use within IETF standards track documents; it might also establish IETF policy for such use.

IETF protocols frequently speak of the "character set" or "charset" of a string, which is used to denote both the character repertoire and the encoding used to represent sequences of characters as sequences of bytes.¶

XML performs all character processing in terms of the Universal Character Set (UCS, [31] and [33]). XML requires all XML processors to support both the UTF-8 [4] and UTF-16 [20] encodings of UCS, although other encodings (charsets) compatible with UCS may be allowed. Documents and external parsed entities encoded in UTF-16 are required to begin with a Byte Order Mark ([8] section 4.3.3).¶

IETF policy [3] requires that the UTF-8 charset be allowed for all text.¶

This document requires that IETF protocols using XML allow for the UTF-8 encoding of XML data. Since conforming XML processors are mandated to also accept UTF-16 encoding, also allowing for UTF-16 encoding (with the mandated Byte Order Mark) is recommended. Some XML applications are using a Byte Order Mark with UTF-8 encoding, but this use should not be encouraged and isn't appropriate for XML embedded in other protocols.¶

Restricting XML data to only be expressed in UTF-8 is an additional syntactic restriction (see Section 4.3) which, depending on circumstances, might add additional implementation complexity. When encodings other than UTF-8 or UTF-16 are used, the encoding must be specified using an "encoding" attribute in the XML declaration (see Section 4.4), even if there might be other protocol mechanisms for designating the encoding.¶

Text encapsulated in XML can be represented in many different human languages, and it is often useful to explicitly identify the language used to present the text. XML defines a special attribute in the "xml" namespace, xml:lang, that can be used to specify the language used to represent data in an XML document. The xml:lang attribute (which has to be explicitly declared for use within a DTD or XML Schema) and the values it can assume are defined in section 2.12 of [8].¶

It is strongly recommended that protocols representing data in a human language mandate use of an xml:lang attribute if the XML instance might be interpreted in language-dependent contexts.¶

There are standard mechanisms in the typography of some human languages that can be difficult to represent using merely XML character string data types. For example, pronunciation clues can be provided using Ruby annotation [39], and embedding controls (such as those described in section 3.4 of [34]) or an XHTML [40] "dir" attribute can be used to note the proper display direction for bidirectional text.¶

There are a number of tricky issues that can arise when using extended character sets with XML document formats. For example: ¶

• There are different ways of representing characters consisting of combining characters, and
• There has been some debate about whether URIs should be represented using a restricted US-ASCII subset or arbitrary Unicode (e.g. "URI character sequence" vs "original character sequence" in RFC 2396 [17]).

Some of these issues are discussed, with recommendations, in the W3C's "Character Model for the World Wide Web" document [44].¶

It is strongly recommended that protocols representing data in a human language reuse existing mechanisms as needed to ensure proper display of human-legible text.¶

9.1. Normative References

[1]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[2]

Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and P. Kocher, “The TLS Protocol Version 1.0”, RFC 2246, January 1999.

[3]

Alvestrand, H., “IETF Policy on Character Sets and Languages”, BCP 18, RFC 2277, January 1998.

[4]

Yergeau, F., “UTF-8, a transformation format of ISO 10646”, RFC 2279, January 1998.

[5]

Murata, M., St. Laurent, S., and D. Kohn, “XML Media Types”, RFC 3023, January 2001.

[6]

Boyer, J., “Canonical XML Version 1.0”, RFC 3076, March 2001.

[7]

Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing”, RFC 3275, March 2002.

[8]

Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed)”, W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.

[9]

Bray, T., Hollander, D., and A. Layman, “Namespaces in XML”, W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.

[10]

Imamura, T., Dillaway, B., Schaad, J., and E. Simon, “XML Encryption Syntax and Processing”, W3C REC-xmlenc-core, October 2001, <http://www.w3.org/TR/xmlenc-core/>.

9.2. Informative References

[11]

Mealling, M., Masinter, L., Hardie, T., and G. Klyne, “An IETF URN Sub-namespace for Registered Protocol Parameters”, Internet-Draft draft-mealling-iana-urn-04 (work in progress), March 2003.

[12]

Mealling, M., “The IETF XML Registry”, Internet-Draft draft-mealling-iana-xmlns-registry-05 (work in progress), June 2003.

[13]

Case, J., Fedor, M., Schoffstall, M., and J. Davin, “Simple Network Management Protocol (SNMP)”, STD 15, RFC 1157, May 1990.

[14]

Srinivasan, R., “XDR: External Data Representation Standard”, RFC 1832, August 1995.

[15]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”, RFC 2045, November 1996.

[16]

Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, November 1997.

[17]

Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998.

[18]

Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

[19]

Rose, M., “Writing I-Ds and RFCs using XML”, RFC 2629, June 1999.

[20]

Hoffman, P. and F. Yergeau, “UTF-16, an encoding of ISO 10646”, RFC 2781, February 2000.

[21]

Klensin, J., “Simple Mail Transfer Protocol”, RFC 2821, April 2001.

[22]

Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, “NFS version 4 Protocol”, RFC 3010, December 2000.

[23]

Kennedy, H., “Binary Lexical Octet Ad-hoc Transport”, RFC 3252, April 2002.

[24]

Popp, N., Mealling, M., and M. Moseley, “Common Name Resolution Protocol (CNRP)”, RFC 3367, August 2002.

[25]

Backus, J., “The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference”, June 1959.

[26]

American National Standards Institute, “Code Extension Techniques for Use with the 7-bit Coded Character Set of American National Standard Code (ASCII) for Information Interchange”, ANSI X3.41, FIPS PUB 35, 1974.

[27]

American National Standards Institute, “Information Retrieval: Application Service Definition and Protocol Specification”, ANSI Z39.50, ISO Standard 23950, 1995.

[28]

International Organization for Standardization, “Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)”, ISO Standard 8824, December 1990.

[29]

International Organization for Standardization, “Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)”, ISO Standard 8825, December 1990.

[30]

International Organization for Standardization, “Information processing - Text and office systems - Standard Generalized Markup Language (SGML)”, ISO Standard 8879, 1988.

[31]

International Organization for Standardization, “Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane”, ISO Standard 10646-1, May 1993.

[32]

International Organization for Standardization, “DSDL Part 0 - Overview”, December 2001, <http://www.jtc1.org/FTP/Public/SC34/DOCREG/0275.htm>.

[33]

Unicode Consortium, “The Unicode Standard, as it may from time to time be revised or amended”, March 2002, <http://www.unicode.org/unicode/standard/standard.html>.

[34]

Duerst, M. and A. Freytag, “Unicode in XML and other Markup Languages”, February 2002, <http://www.w3.org/TR/unicode-xml/>.

[35]

Bray, T., Paoli, J., and C. Sperberg-McQueen, “Extensible Markup Language (XML) 1.0”, W3C REC-xml-1998, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210/>.

[36]

Marsh, J., “XML Base”, W3C REC-xmlbase, June 2001, <http://www.w3.org/TR/xmlbase/>.

[37]

Cowan, J. and R. Tobin, “XML Information Set”, W3C REC-infoset, October 2001, <http://www.w3.org/TR/xml-infoset/>.

[38]

Lassila, O. and R. Swick, “Resource Description Framework (RDF) Model and Syntax Specification”, W3C REC-rdf-syntax, February 1999, <http://www.w3.org/TR/REC-rdf-syntax>.

[39]

Suignard, M., Ishikawa, M., Duerst, M., and T. Texin, “Ruby Annotation”, W3C REC-RUBY, May 2001, <http://www.w3.org/TR/ruby/>.

[40]

Pemberton, S., “XHTML 1.0: The Extensible HyperText Markup Language”, W3C REC-XHTML, January 2000, <http://www.w3.org/TR/xhtml1/>.

[41]

Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, “XML Schema Part 1: Structures”, W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.

[42]

Biron, P. and A. Malhotra, “XML Schema Part 2: Datatypes”, W3C REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.

[43]

Clark, J., “XSL Transformations (XSLT) Version 1.0”, W3C REC-xslt, November 1999, <http://www.w3.org/TR/xslt>.

[44]

Duerst, M., Yergeau, F., Ishida, R., Wolf, M., Freytag, A., and T. Texin, “Character Model for the World Wide Web 1.0”, April 2002, <http://www.w3.org/TR/charmod/>.

[45]

Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, “SOAP Version 1.2 Part 1: Messaging Framework”, June 2002, <http://www.w3.org/TR/soap12-part1/>.

[46]

Gudgin, M., Hadley, M., Moreau, JJ., and H. Nielsen, “SOAP Version 1.2 Part 2: Adjuncts”, June 2002, <http://www.w3.org/TR/soap12-part2/>.

[47]

W3C Communications Team, “XML in 10 points”, November 2001, <http://www.w3.org/XML/1999/XML-in-10-points>.

[48]

OASIS Technical Committee: RELAX NG, “RELAX NG Specification”, December 2001, <http://www.oasis-open.org/committees/relax-ng/spec-20011203.html>.

[49]

Jelliffe, R., “The Schematron”, November 2001, <http://www.ascc.net/xml/schematron/>.