Internet DRAFT - draft-goland-fxpp
draft-goland-fxpp
Internet Engineering Task Force Yaron Y. Goland
INTERNET DRAFT Microsoft Corporation
November 9, 1999
April 2000
Flexible XML Processing Profile (FXPP)
<draft-goland-fxpp-00.txt>
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
<del:glider xmlns:del="http://www.del.jensen.org/">
<del:glidername>
Johnny Updraft
Goland [Page 2]
INTERNET-DRAFT FXPP October 28, 1999
</del:glidername>
<del:glideraccidents/>
</del:glider>
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
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 <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 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.
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.
<?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.
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]
