Internet Engineering Task Force Yaron Y. Goland INTERNET DRAFT Microsoft Corporation November 9, 1999 April 2000 Flexible XML Processing Profile (FXPP) Status of this Memo 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. Please send comments to the SSDP mailing list. Subscription information for the SSDP mailing list is available at http://www.upnp.org/resources/ssdpmail.htm. Abstract This document provides an independent reference for the XML processing profile developed by the WebDAV WG in [RFC2518]. It does this by copying Section 14 and Appendix 4 as well as examples from Appendix 3 of [RFC2518] and editing out any WebDAV specific parts. This information has been broken out into its own independent reference in order to make it easier for other standards to reference just the WebDAV XML processing profile without having to reference the entire WebDAV standard or require their readers to understand which parts of the profile are WebDAV specific and which parts are not. 1. Introduction This document provides an independent reference for the XML processing profile developed by the WebDAV WG in [RFC2518]. It does Goland [Page 1] INTERNET-DRAFT FXPP October 28, 1999 this by copying Section 14 and Appendix 4 as well as examples from Appendix 3 of [RFC2518] and editing out any WebDAV specific parts. This information has been broken out into its own independent reference in order to make it easier for other standards to reference just the WebDAV XML processing profile without having to reference the entire WebDAV standard or require their readers to understand which parts of the profile are WebDAV specific and which parts are not. 2. XML Support Requirement All FXPP compliant systems MUST support [XML]. 3. XML Ignore Rule All FXPP compliant XML processors MUST ignore any unknown XML element and all its children. This rule MAY be overridden on an element by element basis but implementers should be aware that systems unfamiliar with the element will follow the ignore rule. 4. XML Mime Type Support A FXPP compliant system MUST be able to both accept and send text/xml and application/xml. 5. Ordering of XML Elements Unless the definition of a XML element explicitly specifies otherwise the ordering of XML elements has no semantic significance to FXPP compliant systems. Note to Implementers - A generic FXPP compliant XML processor will not know which of the elements it is processing have meaningful ordering. As such, such processors need to maintain the order of the elements when presenting the parsed information so as not to loose any meaningful data. 6. XML Namespace Support All FXPP compliant systems MUST support the XML namespace extensions as specified in [REC-XML-NAMES]. FXPP compliant XML processors MUST interpret a qualified name as a URI constructed by appending the LocalPart to the namespace name URI. Example Johnny Updraft Goland [Page 2] INTERNET-DRAFT FXPP October 28, 1999 In this example, the qualified element name "del:glider" is interpreted as the URL "http://www.del.jensen.org/glider". Johnny Updraft Even though this example is syntactically different from the previous example, it is semantically identical. Each instance of the namespace name "bar" is replaced with "http://www.del.jensen.org/" and then appended to the local name for each element tag. The resulting tag names in this example are exactly the same as for the previous example. Johnny Updraft This example is semantically identical to the two previous ones. Each instance of the namespace name "foo" is replaced with "http://www.del.jensen.org/glide" which is then appended to the local name for each element tag, the resulting tag names are identical to those in the previous examples. 7. XML Element Declaration Syntax The following format is recommended for FXPP compliant specifications as a means to provide uniform declaration of XML elements. Name: Namespace: Purpose: Value: DTD The name is the name of the XML element. The Namespace is the namespace the element belongs to. The purpose is a short description of the use of the XML element. As DTDs are not very good at expressing the format of characters inside of an XML element when an XML element needs to contain formatted pcdata the optional Value Goland [Page 3] INTERNET-DRAFT FXPP October 28, 1999 description will be used to provide a BNF for the character data. At the end of the template is the ELEMENT DTD declaration for the element. 8. Notes on Empty XML Elements XML supports two mechanisms for indicating that an XML element does not have any content. The first is to declare an XML element of the form . The second is to declare an XML element of the form . The two XML elements are semantically identical. It is a violation of the XML specification to use the form if the associated DTD declares the element to be EMPTY (e.g., ). If such a statement is included, then the empty element format, must be used. If the element is not declared to be EMPTY, then either form or may be used for empty elements. 9. Notes on Illegal XML Processing XML is a flexible data format that makes it easy to submit data that appears legal but in fact is not. The philosophy of "Be flexible in what you accept and strict in what you send" still applies, but it must not be applied inappropriately. XML is extremely flexible in dealing with issues of white space, element ordering, inserting new elements, etc. This flexibility does not require extension, especially not in the area of the meaning of elements. There is no kindness in accepting illegal combinations of XML elements. At best it will cause an unwanted result and at worst it can cause real damage. 9.1. Example - XML Syntax Error The following request body for a PROPFIND method is illegal. The definition of the propfind element only allows for the allprop or the propname element, not both. Thus the above is an error and must be responded to with a 400 (Bad Request). Imagine, however, that a server wanted to be "kind" and decided to pick the allprop element as the true element and respond to it. A client running over a bandwidth limited line who intended to execute a propname would be in for a big surprise if the server treated the command as an allprop. Goland [Page 4] INTERNET-DRAFT FXPP October 28, 1999 Additionally, if a server were lenient and decided to reply to this request, the results would vary randomly from server to server, with some servers executing the allprop directive, and others executing the propname directive. This reduces interoperability rather than increasing it. 9.2. Example - Unknown XML Element The previous example was illegal because it contained two elements that were explicitly banned from appearing together in the propfind element. However, XML is an extensible language, so one can imagine new elements being defined for use with propfind. Below is the request body of a PROPFIND and, like the previous example, must be rejected with a 400 (Bad Request) by a server that does not understand the expired-props element. To understand why a 400 (Bad Request) is returned let us look at the request body as the server unfamiliar with expired-props sees it. As the server does not understand the expired-props element, according to the WebDAV-specific XML processing rules specified in section 14 of [RFC 2518], it must ignore it. Thus the server sees an empty propfind, which by the definition of the propfind element is illegal. Please note that had the extension been additive it would not necessarily have resulted in a 400 (Bad Request). For example, imagine the following request body for a PROPFIND: *boss* The previous example contains the fictitious element leave-out. Its purpose is to prevent the return of any property whose name matches the submitted pattern. If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed. Goland [Page 5] INTERNET-DRAFT FXPP October 28, 1999 10. References [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC 2068, January 1997. [RFC2158] Y. Goland, E. Whitehead, A. Faizi, S. Carter, and D. Jensen. HTTP Extensions for Distributed Authoring û WEBDAV. RFC 2518, February 1999. [XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)." World Wide Web Consortium Recommendation REC-xml- 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 11. Author's Addresses Yaron Y. Goland Microsoft Corporation One Microsoft Way Redmond, WA 98052 Email: yarong@microsoft.com This document will expire in April 2000. Goland [Page 6]