UPnP Forum Technical Committee Yaron Y. Goland Document: draft-goland-fxpp-01.txt CrossGain Jeffrey C. Schlimmer Microsoft Corporation 19 June 2000 Flexible XML Processing Profile (FXPP) Status of this Memo This document is under review by the UPnP Forum Technical Committee. It was previously submitted to the IETF as an Internet Draft and has expired. This document is formatted in a manner consistent with the IETF formatting guidelines to facilitate possible future consideration by the IETF. This document is available on http://www.upnp.org. 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 document also defines handling of unknown XML attributes. 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 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 document also defines handling of unknown XML attributes. 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. Goland, Schlimmer 1 UPnP Forum FXPP 19 June 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. XML Support Requirement All FXPP compliant systems MUST support [XML]. 3. XML Ignore Rule All FXPP compliant XML processors (a) MUST ignore any unknown XML element and all its children, and (b) MUST ignore any unknown XML attribute and its value. This rule may be overridden on an element- by-element or attribute-by-attribute basis, but implementers should be aware that systems unfamiliar with the element or attribute 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, Schlimmer 2 UPnP Forum FXPP 19 June 2000 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 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 Goland, Schlimmer 3 UPnP Forum FXPP 19 June 2000 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 WebDAV 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. 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. Goland, Schlimmer 4 UPnP Forum FXPP 19 June 2000 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. 10. References [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. Goland, Schlimmer 5 UPnP Forum FXPP 19 June 2000 [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 CrossGain 2039 152nd Avenue NE Redmond, WA 98052 Jeffrey C. Schlimmer Microsoft Corporation One Microsoft Way Redmond, WA 98052 Goland, Schlimmer 6