| TOC |
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2002.
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document specifies an xmlns Media Feature per RFC 2506 for identifying some or all of the URIs defining XML namespaces in a given XML resource, and the relative importance of these namespaces. This feature is designed primarily for use with the XML Media Types defined in RFC 3023, to provide additional hints as to the processing requirements of a given XML resource.
| TOC |
| TOC |
MIME Content-Type identifiers have proven very useful as tools for describing homogeneous information. They do not fare as well at describing content which is unpredictably heterogeneous. XML documents may be homogeneous, but are also frequently heterogeneous. It is not difficult to create, for instance, an XHTML document which also contains RDF metadata, MathML equations, hypertext using XLink, XForms,and SVG graphics. XSLT stylesheets routinely include information in both the XSLT namespace and in the namespaces of the literal result elements.
RFC 3023 defines a set of XML media types capable of indicating, among other things, a 'most important' type for an XML resource. For example, the content-type header:
indicates that the data is XML and that it should be processed by an XSLT processor. In XML terminology, this is more or less the same as saying that the XSLT 'namespace' is the "most important" namespace relevant to the processing of the data.
This content-type statement does not imply that there is only one namespace associated with the resource, nor does it is necessarily identify the namespace of the root element of the resource. Indeed, this example content-type could easily be associated with a resource whose root element is in the XHTML namespace, but where the resource requires processing by an XSLT processor to generate XHTML output suitable for display.
Moreover, XML data can contain many different 'types' of data, each identified by a namespace URI, and successful processing of a resource may depend on knowledge of some or all of these. For example, using XSLT to produce XHTML output is likely useful only if the recipient is also capable of processing XHTML. Similarly, a program may be better able to choose among a set of XSLT stylesheets if it knows the namespaces of the results they generate, or a renderer may take advantage of foreknowledge to begin setting up components before content actually arrives. Alternatively, processors working with SOAP envelopes may find it useful to know what they will be facing inside the envelope.
The Media feature described in this document can provide additional information about some or all of the namespaces relevant to a given XML resource beyond that indicated by the basic content-type. Such a list can provide guidance to a recipient application as to how best to process the XML data it receives.
It is important to recall that, like all MIME header data, the namespace information in a Media feature is specific to a given application context. Thus the same XML resource, delivered to different applications, may have different namespace information associated with it.
Applications faced with "unknown" XML namespaces may want to attempt to download RDDL documents to collect information on how to process them. Applications may also choose to reject documents containing unknown namespaces.
| TOC |
- Media feature tag name:
- ASN.1 identifier associated with feature tag:
- New assignment by IANA
- Summary of the media feature indicated by this feature tag:
- This feature tag is used to identify XML namespaces either contained in a given document or processable by a given recipient.
- Values appropriate for use with this feature tag:
- The feature tag must contain a String conforming to the RFC 2396 syntax for URI references, as restricted by plenary. URI references must be absolute. Alternatively, in place of a URI, the empty string may be used to represent "no default namespace" as defined in Section 5.2 of Namespaces in XML
- The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms:
- Any protocol that exchanges XML-formatted information in MIME encapsulation
- Examples of typical use:
For an XHTML document containing SVG, MathML, SMIL, and XLink content:
Content-Type: application/xhtml+xml Content-features: (| (xmlns="http://www.w3.org/1998/Math/MathML") (xmlns="http://www.w3.org/2001/SMIL20/") (xmlns="http://www.w3.org/2000/svg") (xmlns="http://www.w3.org/1999/xhtml") (xmlns="http://www.w3.org/1999/xlink") )
Note that order is not important in this list.
Or, using multiple Content-features headings:
Content-Type: application/xhtml+xml Content-features: (xmlns="http://www.w3.org/1998/Math/MathML") Content-features: (xmlns="http://www.w3.org/2001/SMIL20/") Content-features: (xmlns="http://www.w3.org/2000/svg") Content-features: (xmlns="http://www.w3.org/1999/xhtml") Content-features: (xmlns="http://www.w3.org/1999/xlink")
Again, note that order is not important in this list.
For an application indicating that it accepts SMIL, XHTML, or SVG content:
(| (xmlns="http://www.w3.org/2001/SMIL20/");q=1.0 (xmlns="http://www.w3.org/1999/xhtml");q=0.9 (xmlns="http://www.w3.org/2000/svg");q=0.8 )
| TOC |
While XML processing may generally seem like something specific to the XML community, XML's reach is growing rapidly. XML is now in regular use for Web Services (XML-RPC, SOAP), vector graphics (SVG), mathematics (MathML), instant messaging (Jabber), information transformation (XSLT), and a wide variety of other projects.
Because of this general and growing interest, this document recommends registering the 'xmlns' feature in the IETF tree per RFC 2506.
Namespaces are not strictly presentational media information, as are many of the previously registered media features. They do, however, define the set of tools used to present information, much as the type, charset, and language media features do.
While namespaces, especially on the root element, are often linked to a particular MIME Media Type, these connections are not always direct.
There are well-known cases (especially in XSLT) where the root element's relation to the rest of the document is misleading. A commonly-used XSLT practice uses a shell document with stylesheet instructions nested inside. Applications which only look at the namespace of the root document will encounter trouble (whether they notice it or not) in rendering the document as expected by its designers and probable readers.
There are other cases where the root element's relation to the rest of the document is tenuous or even irrelevant. A collection of rules for processing namespaces, for one example, can contain rules in various namespaces, and can even reside quite naturally in documents whose root element has nothing explicit to do with namespace processing.
In these cases, some mechanism must determine the overall MIME Media Type. The list of xmlns Media Features can supplement the Media Type, but applications should look to the Media Type initially.
Security considerations for this registration are listed in the registration above. Considerations for Media Features in general are described in RFC 2506.
Section 2 of this document calls for the registration of a media feature tag, per RFC 2506.
| TOC |
|||Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.|
|||Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.|
|||Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.|
|||Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.|
|||Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.|
|||Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.|
|||Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.|
|||Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.|
|||Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.|
|||Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.|
|||Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.|
|||Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.|
|||Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0", World Wide Web Consortium Recommendation REC-xml, February 1998.|
|||Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml-names, January 1999.|
|||Connolly, D., "W3C XML Plenary Decision on relative URI References In namespace declarations", September 2000.|
|||Borden, J. and T. Bray, "Resource Directory Description Language (RDDL)", June 2001.|
|||Clark , J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation XSLT, November 1999.|
|||Mitra , N., "SOAP Version 1.2", World Wide Web Consortium Working Draft SOAP, December 2001.|
|||Lassila, O. and R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", World Wide Web Consortium Recommendation RDF-syntax, February 1999.|
|||Carlisle, D., Ion, P., Miner, R. and N. Poppelier, "Mathematical Markup Language 2.0 (MathML)", World Wide Web Consortium Recommendation MathML, February 2001.|
|||Ferraiolo, J., "Scalable Vector Graphics (SVG)", World Wide Web Consortium Working Draft SVG, August 1999.|
|||DeRose, S., Maler, E. and D. Orchard, "XML Linking Language (XLink)", World Wide Web Consortium Recommendation XLink, June 2001.|
|||DeRose, S., Daniel Jr., R. and E. Maler, "XML Pointer Language (XPointer)", World Wide Web Consortium Working Draft XPointer, July 1999.|
|||Marsh, J., "XML Base", World Wide Web Consortium Recommendation XML Base, June 2000.|
|||Dubinko, M., Dietl, J., Klotz, L., Merrick, R. and T. Raman, "XForms 1.0", World Wide Web Consortium Working Draft XForms, January 2002.|
|||Pemberton, S. and et al, "XHTML 1.0: The Extensible HyperText Markup Language", World Wide Web Consortium Recommendation REC-xhtml1, January 2000.|
|||Altheim, M. and S. McCarron, "XHTML 1.1: Module-based XHTML", World Wide Web Consortium Recommendation REC-xhtml11, January 2000.|
|||St.Laurent, S., "Namespaces for Namespace-based Processing", September 2001.|
| TOC |
|O'Reilly & Associates|
|1259 Dryden Road|
|Ithaca, New York 14850|
|Emfisys, Bank of Montreal|
|120 Bloor Street E, 5th Floor|
|Toronto, Ontario M4W 3X1|
| TOC |
Thanks to Graham Klyne, Jonathan Borden, Murata Makoto, Edd Dumbill, and Eric van der Vlist for editorial and technical comments on an early version of this document. Their help does not, of course, constitute endorsement.
Additional thanks to Mark Baker, Don Box, Tim Bray, Paul Prescod, Ian Graham, G. Ken Holman, Mark Nottingham, and Len Bullard for suggestions and discussion.
| TOC |
00 - First version.
01 - Fixed typos in abstract and introduction. Restored colons to examples. Added XForms to introduction. Added section "Relation to MIME Media Types". Added references for XForms and Namespaces for Namespace-based Processing.
02 - Made it explicit that sequence does not matter in Content-features headers. Added language permitting "no default namespace" as does Namespaces in XML. Tightened up description of XSLT stylesheet contents. Reorganized front-matter per suggestions from Ian Graham. Added Ian as co-author.
[To be deleted before publication.]
| TOC |
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.