One document matched: draft-mehta-atom-inline-00.xml


<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
	<!ENTITY rfc3023 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml'>
	<!ENTITY rfc3548 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3548.xml'>
	<!ENTITY rfc3986 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
	<!ENTITY rfc4287 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml'>
	<!ENTITY rfc4288 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.xml'>
	<!ENTITY recxhtml PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml2/reference.W3C.REC-XHTML.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc tocdepth="3" ?>
<rfc category="exp" ipr="trust200811" docName="draft-mehta-atom-inline-00">
	<front>
		<title abbrev="Atom In-line Extensions">In-lining Extensions for Atom</title>
		<author initials="N. R." surname="Mehta" fullname="Nikunj R. Mehta">
			<organization>Oracle Corp.</organization>
			<address>
				<email>nikunj.mehta@oracle.com</email>
				<uri>http://o-micron.blogspot.com/</uri>
			</address>
		</author>
		<date day="9" month="June" year="2009"/>
		<abstract>
			<t>
			This specification defines mechanisms for in-lining representations of
      linked resources in Atom documents.
 			</t>
		</abstract>
		<note title="Editorial Note">
			<t>
			To provide feedback on this Internet-Draft, join the
			<eref target="http://www.imc.org/atom-syntax/">atom-syntax mailing
			list (http://www.imc.org/atom-syntax/)</eref>.
			</t>
		</note>
	</front>
	<middle>
		<section anchor="intro" title="Introduction">
			<t>
			This document defines an extension for in-line representations of 
      linked resources within the Atom Syndication Format <xref target="RFC4287"/>. Such
      in-line representations can be either text, binary, or well-formed XML.
      </t>
			<section title="Namespace">
				<t> The XML Namespaces URI for the XML data format described in this specification is: </t>
				<figure width="" align="left" height="" alt="" title="">
					<artwork name="" align="left" height="" width="" alt="" type="" xml:space="preserve">
    http://purl.org/atom/ext/</artwork>
				</figure>
				<t> This specification uses the prefix "ae:" for the namespace name.  The
       prefix "atom:" is used for "http://www.w3.org/2005/Atom", the namespace name of
       the Atom Syndication Format <xref target="RFC4287"/>.
       These namespace prefixes are not semantically significant.
       </t>
			</section>
			<section title="Notational Conventions">
        <t>
        Some sections of this specification are illustrated with fragments of a
        non-normative RELAX NG Compact schema <xref target="RELAXNG"/>. In those sections, this 
        specification uses the xhtmlDiv, atomCommonAttributes, atomMediaType and 
        anyElement, defined in <xref target="RFC4287"/>.
        </t>
        <t>
        However, the text of this specification provides the definition of conformance.  
        </t>
				<t>
				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 <xref target="RFC2119"/>.
				</t>
			</section>
      <section title="Terminology" anchor="terminology">
        <t>
          This specification uses Atom link relations to identify different
          types of links; see the Atom specification <xref target="RFC4287"/> for
          information about their syntax, and the IANA link relation registry
          for more information about specific values.
         </t>
       </section>
		</section>
		<section title="In-line Representation of Resources" anchor="inline-representation">
			<t>
      Some applications require the ability to pre-fetch resources linked from an 
      Atom document using the atom:link element <xref target="RFC4287"/>. Such 
      in-line representations are similar to the in-line content model of Atom.
			</t>
			<t>
      An Atom document MAY include the in-line representation of a linked resource 
      by using the ae:inline element inside the corresponding atom:link element.
      The in-lined representation is only a hint and MAY differ from the 
      representation obtained from the URI referenced in the link. Atom Processors 
      SHOULD use the link URI to obtain the complete representation of the linked resource.
 		  </t>
      <section title="The "ae:inline" Extension Element" anchor="inline-element">
        <t>
        The "ae:inline" element contains an approximate representation of the linked resource.
        </t>
				<figure>
					<preamble/>
					<artwork name="inline-definition" type="definition"><![CDATA[
extensionInlineTextRepresentation = 
   element ae:inline {
      atomCommonAttributes,
      attribute type {"text" | "html"}?,
      (text)*
   }
   
extensionInlineXHTMLRepresentation = 
   element ae:inline {
      atomCommonAttributes,
      attribute type {"xhtml"},
      xhtmlDiv
   }
   
extensionInlineAtomRepresentation = 
   element ae:inline {
      atomCommonAttributes,
      attribute type {"feed" | "entry"},
      atomFeed | atomEntry
   }

extensionInlineOtherRepresentation =
   element ae:inline {
      atomCommonAttributes,
      attribute type { atomMediaType }?,
      (text|anyElement)*
   }

extensionInlineEmpty = 
   element ae:inline {
      atomCommonAttributes,
      empty
   }

extensionInline = extensionInlineTextRepresentation 
 | extensionInlineXHTMLRepresentation
 | extensionInlineAtomRepresentation
 | extensionInlineOtherRepresentation
 | extensionInlineEmpty
 ]]></artwork>
        </figure>
        
        <section title="Empty "ae:inline" Element" anchor="empty-inline">
        <t>
        The ae:inline element may be empty if the producer of the Atom document 
        a linked resource cannot be in-lined, e.g., due to inadequate authorization
        or if the resource does not yet exist. 
        </t>
        </section>
        
        <section title="The "type" Attribute" anchor="type-attribute">
        <t>
           On the ae:inline element, the value of the "type" attribute MAY be
   one of "text", "html", "xhtml", "entry", or "feed".  Failing that, it MUST 
   conform to the syntax of a MIME media type, but MUST NOT be a composite type
   (see Section 4.2.6 of <xref target="RFC4288"/>).  If the type attribute is not provided, 
   Atom Processors MUST behave as though the type attribute were present with
   a value of "text".
        </t>
        <t>
        The type attributes on an atom:link element and its nested ae:inline
        element may not match. 
        </t>
        </section>
        
        <section title="Processing Model" anchor="processing-model">
        <t>
        Use of the in-line extensions MUST conform to the following 
        rules. Conforming Atom Processors MUST interpret ae:inline 
        according to the first applicable rule:
          <list style="numbers">
          <t>
       If the value of "type" is "text", the content of ae:inline
       MUST NOT contain child elements.  Such text is intended to be
       presented to humans in a readable fashion.  Thus, Atom Processors
       MAY collapse white space (including line breaks), and display the
       text using typographic techniques such as justification and
       proportional fonts.
          </t>
          <t>
       If the value of "type" is "html", the content of ae:inline
       MUST NOT contain child elements and SHOULD be suitable for
       handling as HTML <xref target="HTML"/>.  The HTML markup MUST be escaped; for
       example, "<br>" as "&lt;br>".  The HTML markup SHOULD be such
       that it could validly appear directly within an HTML <DIV>
       element.  Atom Processors that display the content MAY use the
       markup to aid in displaying it.
          </t>
          <t>
       If the value of "type" is "xhtml", the content of ae:inline
       MUST be a single XHTML div element <xref target="W3C.REC-XHTML"/> and SHOULD be suitable
       for handling as XHTML.  The XHTML div element itself MUST NOT be
       considered part of the content.  Atom Processors that display the
       content MAY use the markup to aid in displaying it.  The escaped
       versions of characters such as "&" and ">" represent those
       characters, not markup.
          </t>
          <t>
       If the value of "type" is "entry", the content of atom:content
       MUST be a single ATOM entry element <xref target="RFC4287"/>.  
          </t>
          <t>
       If the value of "type" is "feed", the content of atom:content
       MUST be a single ATOM feed element <xref target="RFC4287"/>.  
          </t>
          <t>
       If the value of "type" is an XML media type <xref target="RFC3023"/> or ends
       with "+xml" or "/xml" (case insensitive), the content of
       ae:inline MAY include child elements and SHOULD be suitable
       for handling as the indicated media type.  This would normally 
       mean that the "ae:inline" element would contain a single child 
       element that would serve as the root element of the XML 
       document of the indicated type.
          </t>
          <t>
       If the value of "type" begins with "text/" (case insensitive),
       the content of ae:inline MUST NOT contain child elements.
          </t>
          <t>
       For all other values of "type", the content of atom:content MUST
       be a valid Base64 encoding, as described in <xref target="RFC3548"/>, section 3.
       When decoded, it SHOULD be suitable for handling as the indicated
       media type.  In this case, the characters in the Base64 encoding
       MAY be preceded and followed in the atom:content element by white
       space, and lines are separated by a single newline (U+000A)
       character.
          </t>
          </list>
        </t>
        </section>       
      </section>
				
    </section>
		<section title="Examples" anchor="examples">
      <section title="Feed with in-line replies link" anchor="replies-feed-example">  
				<figure>
					<artwork name="In line replies link" type="example"><![CDATA[
<feed xmlns="http://www.w3.org/2005/Atom"
         xmlns:thr="http://purl.org/syndication/thread/1.0">
    <id>http://www.example.org/entries</id>
    <title>My posts</title>
    <updated>2006-03-01T12:12:12Z</updated>
    <link rel="replies" thr:count="10"
      href="http://www.example.org/replies">
      <ae:inline xmlns:ae="http://purl.org/atom/ext/"
        type="feed">
        <feed>
        ...
        </feed>
      </ae:inline>
    </link>
    <link rel="self" 
      href="http://www.example.org/entries" />
    ...
</feed>
 ]]></artwork>
			</figure>
    </section>
    <section title="Entry with in-line up link" anchor="up-entry-example">
			<figure>
				<artwork name="In-line up entry" type="example"><![CDATA[
<entry xmlns="http://www.w3.org/2005/Atom">
  <link rel="up" type="application/atom+xml"
    href="/finance/feeds/default/portfolios/1">
    <ae:inline type="entry">
      <atom:entry>
         ...
      </atom:entry>
    </ae:inline>
  </atom:link>
  <atom:link rel="edit" 
     href="/finance/feeds/default/portfolios/1/positions/NASDAQ:ORCL"/>
  ...
</atom:entry>
	 ]]></artwork>
				</figure>
			</section>
    </section>
		<section title="Security Considerations">
			<t>
			In-line Extensions for Atom are subject to the security considerations found in Section 8 of <xref target="RFC4287"/>.
			</t>
      <t>
      In-line representations can overwhelm Atom processors. For this reason, consumers
      of Atom representations should take adequate precautions to limit resource
      consumption when processing ae:inline elements.
      </t>
		</section>
	</middle>
	<back>
		<references title="Normative References">
      <reference 
        anchor="HTML" 
        target="http://www.w3.org/TR/1999/REC-html401-19991224">
        <front>
          <title>HTML 4.01 Specification, W3C REC REC-html401-19991224</title>
          <author initials="D" surname="Raggett" fullname="D Raggett">
            <organization />
          </author>
          <author initials="A" surname="Hors" fullname="A Hors">
            <organization />
          </author>
          <author initials="I" surname="Jacobs" fullname="Ian Jacobs">
            <organization />
          </author>
          <date month="December" year="1999" />
        </front>
      </reference>
		   &rfc2119;
       &rfc3023;
       &rfc3548;
		   &rfc3986;
		   &rfc4287;
       &rfc4288;
       &recxhtml;
    </references>
    <references title="Informative References">
      <reference 
        anchor="RELAXNG" 
        target="http://www.oasis-open.org/committees/relax-ng/compact-20021121.html">
        <front>
          <title>RELAX NG Compact Syntax</title>
          <author initials="J" surname="Clark" fullname="James Clark">
            <organization />
          </author>
          <date month="December" year="2001" />
        </front>
      </reference>
    </references>
    <section title="Acknowledgements">
			<t>
			On the atom-syntax mailing list, Hadrien Gardeur, Al Brown, Julian Reschke,  
      Mark Nottingham, Pablo Castro, Kyle Marvin, and James Snell
      provided very valuable feedback to solidify this draft. 
			</t>
		</section>
		<section title="Revision History">
			<t>
			00 - Initial Revision, split from draft-divilly-atom-hierarchy-01.
      </t>
		</section>
	</back>
</rfc>

PAFTECH AB 2003-20262026-04-24 15:03:06