pymeds/docs/draft-goland-fxpp-01.txt

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 
    
   <del:glider xmlns:del="http://www.del.jensen.org/">  
      <del:glidername>  
        Johnny Updraft  
      </del:glidername>  
      <del:glideraccidents/>  
   </del:glider>  
    

     
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". 
    
   <bar:glider xmlns:bar="http://www.del.jensen.org/">  
      <bar:glidername>  
         Johnny Updraft  
      </bar:glidername>  
      <bar:glideraccidents/>  
   </bar:glider>  
    
   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. 
    
   <foo:r xmlns:foo="http://www.del.jensen.org/glide">  
      <foo:rname>  
         Johnny Updraft  
      </foo:rname>  
      <foo:raccidents/>  
   </foo:r>  
    
   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 <A></A>.  The second is to declare an XML element of the form 
   <A/>.  The two XML elements are semantically identical. 
    
   It is a violation of the XML specification to use the <A></A> form 
   if the associated DTD declares the element to be EMPTY (e.g., 
   <!ELEMENT A EMPTY>).  If such a statement is included, then the 
   empty element format, <A/> must be used.  If the element is not 
   declared to be EMPTY, then either form <A></A> or <A/> 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. 
    
   <?xml version="1.0" encoding="utf-8" ?>  
   <D:propfind xmlns:D="DAV:">  
      <D:allprop/>  
      <D:propname/>  
   </D:propfind>  
    
   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. 
    
   <?xml version="1.0" encoding="utf-8" ?>  
   <D:propfind xmlns:D="DAV:"  
         xmlns:E="http://www.foo.bar/standards/props/">  
      <E:expired-props/>  
   </D:propfind>  
    
   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. 
    
   <?xml version="1.0" encoding="utf-8" ?>  
   <D:propfind xmlns:D="DAV:"  
         xmlns:E="http://www.foo.bar/standards/props/">  
   </D:propfind>  
    
   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: 
    
   <?xml version="1.0" encoding="utf-8" ?>  
   <D:propfind xmlns:D="DAV:"  
         xmlns:E="http://www.foo.bar/standards/props/">  
      <D:propname/>  
      <E:leave-out>*boss*</E:leave-out>  
   </D:propfind>  
    
   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 
   <mailto:yarongo@crossgain.com> 
    
   Jeffrey C. Schlimmer 
   Microsoft Corporation 
   One Microsoft Way 
   Redmond, WA 98052 
   <mailto:jeffsch@Microsoft.com> 




























     
Goland, Schlimmer                                                    6