activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cmacn...@apache.org
Subject svn commit: r898181 [1/5] - in /activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator: ./ specification/ specification/1.0-PR2/ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/activemq/ src/m...
Date Tue, 12 Jan 2010 04:23:34 GMT
Author: cmacnaug
Date: Tue Jan 12 04:23:30 2010
New Revision: 898181

URL: http://svn.apache.org/viewvc?rev=898181&view=rev
Log:
Start of AMQP 1.0 protocol generator.

Added:
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/   (with props)
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/security.xml
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/transport.xml
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/types.xml
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpChoice.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpClass.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpDescriptor.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpDoc.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpEncoding.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpException.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/AmqpField.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Generator.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/JAXBGen.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Main.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Marshalable.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/TypeRegistry.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/UnknownTypeException.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/Utils.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Amqp.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/B.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Choice.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Dd.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Definition.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Descriptor.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Dl.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Doc.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Dt.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Encoding.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Exception.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Field.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/I.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Li.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/ObjectFactory.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Ol.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/P.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Picture.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Section.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Sub.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Sup.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Type.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Ul.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/main/java/org/apache/activemq/amqp/generator/jaxb/schema/Xref.java
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/activemq/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/activemq/amqp/
    activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/src/test/java/org/apache/activemq/amqp/generator/

Propchange: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/
------------------------------------------------------------------------------
--- svn:ignore (added)
+++ svn:ignore Tue Jan 12 04:23:30 2010
@@ -0,0 +1,4 @@
+.classpath
+.project
+.settings
+target

Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/pom.xml Tue Jan 12 04:23:30 2010
@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?><project>
+  <parent>
+    <artifactId>activemq-parent</artifactId>
+    <groupId>org.apache.activemq</groupId>
+    <version>6.0-SNAPSHOT</version>
+  </parent>
+  <modelVersion>4.0.0</modelVersion>
+  <groupId>org.apache.activemq</groupId>
+  <artifactId>activemq-amqp-generator</artifactId>
+  <name>activemq-amqp-generator</name>
+  <version>6.0-SNAPSHOT</version>
+  <url>http://maven.apache.org</url>
+  <repositories>
+  	<repository>
+  		<id>repo1.maven.org</id>
+  		<name>Maven central</name>
+  		<url>http://repo1.maven.org/maven2</url>
+  	</repository>
+  </repositories>
+  <dependencies>
+    <dependency>
+      <groupId>junit</groupId>
+      <artifactId>junit</artifactId>
+      <version>3.8.1</version>
+      <scope>test</scope>
+    </dependency>
+    <dependency>
+    	<groupId>org.apache.velocity</groupId>
+    	<artifactId>velocity</artifactId>
+    	<version>1.6</version>
+    </dependency>
+    <dependency>
+    	<groupId>javax.xml</groupId>
+    	<artifactId>jaxb-api</artifactId>
+    	<version>2.1</version>
+    </dependency>
+    <dependency>
+    	<groupId>commons-logging</groupId>
+    	<artifactId>commons-logging-api</artifactId>
+    	<version>1.1</version>
+    </dependency>
+    <dependency>
+    	<groupId>log4j</groupId>
+    	<artifactId>log4j</artifactId>
+    	<version>1.2.15</version>
+    	<scope>runtime</scope>
+    </dependency>
+  </dependencies>
+</project>
\ No newline at end of file

Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/amqp.dtd Tue Jan 12 04:23:30 2010
@@ -0,0 +1,212 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!--
+  Copyright Notice
+  ================
+  (c) Copyright Cisco Systems, Credit Suisse, Deutsche Börse Systems, Envoy Technologies, Inc.,
+  Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+  Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc
+  2006, 2007. All rights reserved.
+
+  License
+  =======
+  JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA
+  Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. (collectively, the
+  "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
+  nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
+  Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
+  the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
+  any rights under this Agreement will terminate immediately without notice from any Author if you
+  bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
+  Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
+  Messaging Queue Protocol Specification in your possession or control.
+
+  As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
+  throughout the world, excluding design patents and design registrations, owned or controlled, or
+  that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
+  an Author or its affiliates now or at any future time and which would necessarily be infringed by
+  implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
+  infringed hereunder only when it is not possible to avoid infringing it because there is no
+  plausible non-infringing alternative for implementing the required portions of the Advanced
+  Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
+  include any claims other than as set forth above even if contained in the same patent as Licensed
+  Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
+  Protocol Specification that are not required by the Advanced Messaging Queue Protocol
+  Specification, or that, if licensed, would require a payment of royalties by the licensor to
+  unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
+  technologies that may be necessary to make or use any Licensed Product but are not themselves
+  expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
+  manufacturing technology, compiler technology, object oriented technology, networking technology,
+  operating system technology, and the like); or (ii) the implementation of other published
+  standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
+  Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
+  function of which is not required for compliance with the Advanced Messaging Queue Protocol
+  Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
+  Specification shall be deemed to include both architectural and interconnection requirements
+  essential for interoperability and may also include supporting source code artifacts where such
+  architectural, interconnection requirements and source code artifacts are expressly identified as
+  being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
+  Specification.
+
+  As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
+  software or combinations thereof) that implement and are compliant with all relevant portions of
+  the Advanced Messaging Queue Protocol Specification.
+
+  The following disclaimers, which you hereby also acknowledge as to any use you may make of the
+  Advanced Messaging Queue Protocol Specification:
+
+  THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
+  REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
+  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
+  OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
+  IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
+  PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+  THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
+  DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR OF THE ADVANCED
+  MESSAGING QUEUE PROTOCOL SPECIFICATION.
+
+  The name and trademarks of the Authors may NOT be used in any manner, including advertising or
+  publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
+  without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
+  Protocol Specification will at all times remain with the Authors.
+
+  No other rights are granted by implication, estoppel or otherwise.
+
+  Upon termination of your license or rights under this Agreement, you shall destroy all copies of
+  the Advanced Messaging Queue Protocol Specification in your possession or control.
+
+  Trademarks
+  ==========
+  "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
+  trademarks of JPMorgan Chase & Co.
+
+  IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
+
+  IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
+  subsidiaries.
+
+  LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
+  Inc. in the US and other countries.
+
+  Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
+  United States, other countries, or both.
+
+  Other company, product, or service names may be trademarks or service marks of others.
+
+  Links to full AMQP specification:
+  =================================
+  http://www.envoytech.org/spec/amq/
+  http://www.iona.com/opensource/amqp/
+  http://www.redhat.com/solutions/specifications/amqp/
+  http://www.twiststandards.org/tiki-index.php?page=AMQ
+  http://www.imatix.com/amqp
+-->
+
+<!ELEMENT amqp (doc|section)*>
+<!ATTLIST amqp
+          xmlns CDATA #IMPLIED
+          name CDATA #REQUIRED
+	  label CDATA #IMPLIED
+>
+
+<!ELEMENT section (doc|definition|type)*>
+<!ATTLIST section
+          name CDATA #REQUIRED
+          title CDATA #IMPLIED
+          label CDATA #IMPLIED
+>
+
+<!ELEMENT definition (doc)*>
+<!ATTLIST definition
+	  name CDATA #REQUIRED
+	  value CDATA #REQUIRED
+	  label CDATA #IMPLIED
+>
+
+<!ELEMENT type (encoding|descriptor|field|choice|exception|doc)*>
+<!ATTLIST type
+          name CDATA #REQUIRED
+          class (primitive|compound|restricted|union) #REQUIRED
+          source CDATA #IMPLIED
+          label CDATA #IMPLIED
+>
+
+<!ELEMENT encoding (doc)*>
+<!ATTLIST encoding
+          name CDATA #IMPLIED
+          label CDATA #IMPLIED
+          code CDATA #REQUIRED
+          category (fixed|variable|compound|array) #REQUIRED
+          width CDATA #IMPLIED
+>
+
+
+<!ELEMENT descriptor (doc)*>
+<!ATTLIST descriptor
+          name CDATA #IMPLIED
+          code CDATA #IMPLIED
+>
+
+<!ELEMENT field (doc|exception)*>
+<!ATTLIST field
+	  name CDATA #REQUIRED
+	  type CDATA #IMPLIED
+          default CDATA #IMPLIED
+          label CDATA #IMPLIED
+          required CDATA #IMPLIED
+          multiple CDATA #IMPLIED
+>
+
+<!ELEMENT choice (doc)*>
+<!ATTLIST choice
+          name CDATA #REQUIRED
+          value CDATA #REQUIRED
+>
+
+<!ELEMENT exception (doc)*>
+<!ATTLIST exception
+	  name CDATA #REQUIRED
+	  error-code CDATA #IMPLIED
+>
+
+<!ELEMENT doc (p|ul|ol|dl|picture)*>
+<!ATTLIST doc
+	  title CDATA #IMPLIED
+>
+
+<!ELEMENT p (#PCDATA|xref|b|i|sup|sub)*>
+
+<!ELEMENT xref (#PCDATA)>
+<!ATTLIST xref
+          type CDATA #IMPLIED
+          name CDATA #REQUIRED
+>
+
+<!ELEMENT b (#PCDATA)>
+<!ELEMENT i (#PCDATA)>
+<!ELEMENT sup (#PCDATA|sup|sub|b|i)*>
+<!ELEMENT sub (#PCDATA|sup|sub|b|i)*>
+
+<!ELEMENT ul (li)*>
+<!ATTLIST ul
+	  title CDATA #IMPLIED
+>
+<!ELEMENT ol (li)*>
+<!ATTLIST ol
+	  title CDATA #IMPLIED
+>
+
+<!ELEMENT li (p|ul)*>
+
+<!ELEMENT dl (dt, dd)*>
+<!ATTLIST dl
+	  title CDATA #IMPLIED
+>
+<!ELEMENT dt (#PCDATA)>
+<!ELEMENT dd (p)*>
+
+<!ELEMENT picture (#PCDATA)>
+<!ATTLIST picture
+	  title CDATA #IMPLIED
+>

Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/index.xml Tue Jan 12 04:23:30 2010
@@ -0,0 +1,122 @@
+<?xml version="1.0"?>
+
+<!--
+  Copyright Notice
+  ================
+  (c) Copyright Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,
+  Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+  Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc.
+  2006, 2007. All rights reserved.
+
+  License
+  =======
+
+  Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,Goldman Sachs,
+  IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, Novell, Rabbit
+  Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc. (collectively,
+  the "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
+  nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
+  Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
+  the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
+  any rights under this Agreement will terminate immediately without notice from any Author if you
+  bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
+  Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
+  Messaging Queue Protocol Specification in your possession or control.
+
+  As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
+  throughout the world, excluding design patents and design registrations, owned or controlled, or
+  that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
+  an Author or its affiliates now or at any future time and which would necessarily be infringed by
+  implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
+  infringed hereunder only when it is not possible to avoid infringing it because there is no
+  plausible non-infringing alternative for implementing the required portions of the Advanced
+  Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
+  include any claims other than as set forth above even if contained in the same patent as Licensed
+  Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
+  Protocol Specification that are not required by the Advanced Messaging Queue Protocol
+  Specification, or that, if licensed, would require a payment of royalties by the licensor to
+  unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
+  technologies that may be necessary to make or use any Licensed Product but are not themselves
+  expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
+  manufacturing technology, compiler technology, object oriented technology, networking technology,
+  operating system technology, and the like); or (ii) the implementation of other published
+  standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
+  Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
+  function of which is not required for compliance with the Advanced Messaging Queue Protocol
+  Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
+  Specification shall be deemed to include both architectural and interconnection requirements
+  essential for interoperability and may also include supporting source code artifacts where such
+  architectural, interconnection requirements and source code artifacts are expressly identified as
+  being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
+  Specification.
+
+  As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
+  software or combinations thereof) that implement and are compliant with all relevant portions of
+  the Advanced Messaging Queue Protocol Specification.
+
+  The following disclaimers, which you hereby also acknowledge as to any use you may make of the
+  Advanced Messaging Queue Protocol Specification:
+
+  THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
+  REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
+  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
+  OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
+  IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
+  PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+  THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
+  DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED
+  MESSAGING QUEUE PROTOCOL SPECIFICATION.
+
+  The name and trademarks of the Authors may NOT be used in any manner, including advertising or
+  publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
+  without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
+  Protocol Specification will at all times remain with the Authors.
+
+  No other rights are granted by implication, estoppel or otherwise.
+
+  Upon termination of your license or rights under this Agreement, you shall destroy all copies of
+  the Advanced Messaging Queue Protocol Specification in your possession or control.
+
+  Trademarks
+  ==========
+  "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
+  trademarks of JPMorgan Chase & Co.
+
+  IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
+
+  IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
+  subsidiaries.
+
+  LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
+  Inc. in the US and other countries.
+
+  Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
+  United States, other countries, or both.
+
+  Other company, product, or service names may be trademarks or service marks of others.
+
+  Links to full AMQP specification:
+  =================================
+  http://www.envoytech.org/spec/amq/
+  http://www.iona.com/opensource/amqp/
+  http://www.redhat.com/solutions/specifications/amqp/
+  http://www.twiststandards.org/tiki-index.php?page=AMQ
+  http://www.imatix.com/amqp
+-->
+
+<!DOCTYPE amqp SYSTEM "amqp.dtd">
+
+<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
+      name="index" label="working version">
+
+  <doc>
+    <ul>
+      <li><p><xref type="amqp" name="types"/></p></li>
+      <li><p><xref type="amqp" name="transport"/></p></li>
+      <li><p><xref type="amqp" name="messaging"/></p></li>
+      <li><p><xref type="amqp" name="security"/></p></li>
+    </ul>
+  </doc>
+
+</amqp>

Added: activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml
URL: http://svn.apache.org/viewvc/activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml?rev=898181&view=auto
==============================================================================
--- activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml (added)
+++ activemq/sandbox/activemq-apollo-actor/activemq-amqp-generator/specification/1.0-PR2/messaging.xml Tue Jan 12 04:23:30 2010
@@ -0,0 +1,1139 @@
+<?xml version="1.0"?>
+
+<!--
+  Copyright Notice
+  ================
+  (c) Copyright Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,
+  Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+  Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc.
+  2006, 2007. All rights reserved.
+
+  License
+  =======
+
+  Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,Goldman Sachs,
+  IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, Novell, Rabbit
+  Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc. (collectively,
+  the "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
+  nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
+  Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
+  the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
+  any rights under this Agreement will terminate immediately without notice from any Author if you
+  bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
+  Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
+  Messaging Queue Protocol Specification in your possession or control.
+
+  As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
+  throughout the world, excluding design patents and design registrations, owned or controlled, or
+  that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
+  an Author or its affiliates now or at any future time and which would necessarily be infringed by
+  implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
+  infringed hereunder only when it is not possible to avoid infringing it because there is no
+  plausible non-infringing alternative for implementing the required portions of the Advanced
+  Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
+  include any claims other than as set forth above even if contained in the same patent as Licensed
+  Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
+  Protocol Specification that are not required by the Advanced Messaging Queue Protocol
+  Specification, or that, if licensed, would require a payment of royalties by the licensor to
+  unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
+  technologies that may be necessary to make or use any Licensed Product but are not themselves
+  expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
+  manufacturing technology, compiler technology, object oriented technology, networking technology,
+  operating system technology, and the like); or (ii) the implementation of other published
+  standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
+  Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
+  function of which is not required for compliance with the Advanced Messaging Queue Protocol
+  Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
+  Specification shall be deemed to include both architectural and interconnection requirements
+  essential for interoperability and may also include supporting source code artifacts where such
+  architectural, interconnection requirements and source code artifacts are expressly identified as
+  being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
+  Specification.
+
+  As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
+  software or combinations thereof) that implement and are compliant with all relevant portions of
+  the Advanced Messaging Queue Protocol Specification.
+
+  The following disclaimers, which you hereby also acknowledge as to any use you may make of the
+  Advanced Messaging Queue Protocol Specification:
+
+  THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
+  REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
+  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
+  OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
+  IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
+  PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
+
+  THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
+  DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED
+  MESSAGING QUEUE PROTOCOL SPECIFICATION.
+
+  The name and trademarks of the Authors may NOT be used in any manner, including advertising or
+  publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
+  without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
+  Protocol Specification will at all times remain with the Authors.
+
+  No other rights are granted by implication, estoppel or otherwise.
+
+  Upon termination of your license or rights under this Agreement, you shall destroy all copies of
+  the Advanced Messaging Queue Protocol Specification in your possession or control.
+
+  Trademarks
+  ==========
+  "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
+  trademarks of JPMorgan Chase & Co.
+
+  IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
+
+  IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
+  subsidiaries.
+
+  LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
+  Inc. in the US and other countries.
+
+  Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
+  United States, other countries, or both.
+
+  Other company, product, or service names may be trademarks or service marks of others.
+
+  Links to full AMQP specification:
+  =================================
+  http://www.envoytech.org/spec/amq/
+  http://www.iona.com/opensource/amqp/
+  http://www.redhat.com/solutions/specifications/amqp/
+  http://www.twiststandards.org/tiki-index.php?page=AMQ
+  http://www.imatix.com/amqp
+-->
+
+<!DOCTYPE amqp SYSTEM "amqp.dtd">
+
+<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
+      name="messaging" label="working version">
+
+  <section name="introduction" label="introduction to the Messaging layer">
+    <doc>
+      <p>
+        The messaging layer builds on top of the concepts described in books II and III. The
+        <xref name="transport"/> layer defines a number of extension points suitable for use in a
+        variety of different messaging applications. The messaging layer specifies a standardized
+        use of these to provide interoperable messaging capabilities. This standard covers:
+      </p>
+
+      <ul>
+        <li>
+          <p>properties for the bare message</p>
+        </li>
+
+        <li>
+          <p>formats for structured and unstructured sections in the bare message</p>
+        </li>
+
+        <li>
+          <p>headers and footers for the annotated message</p>
+        </li>
+
+        <li>
+          <p>formats for sources and targets</p>
+
+          <ul>
+            <li>
+              <p>destructive and non-destructive access to messages from a node</p>
+            </li>
+
+            <li>
+              <p>filtering of messages from a node</p>
+            </li>
+
+            <li>
+              <p>default disposition of transfers</p>
+            </li>
+
+            <li>
+              <p>disposition of orphaned transfers</p>
+            </li>
+
+            <li>
+              <p>on-demand node creation</p>
+            </li>
+          </ul>
+        </li>
+
+        <li>
+          <p>states for messages held in a node</p>
+        </li>
+
+        <li>
+          <p>dispositions for messages transferred to/from a node</p>
+        </li>
+
+        <li>
+          <p>a transactional model for modifying the state of messages held in a node</p>
+        </li>
+      </ul>
+    </doc>
+  </section>
+
+  <section name="message-format" title="Message Format" label="Message format definitions">
+
+    <doc>
+      <p>
+        The term message is used with various connotations in the messaging world. The sender may
+        like to think of the message as an immutable payload handed off to the messaging
+        infrastructure for delivery. The receiver often thinks of the message as not only that
+        immutable payload from the sender, but also various annotations supplied by the messaging
+        infrastructure along the way. To avoid confusion we formally define the term <i>bare
+        message</i> to mean the message as supplied by the sender and the term <i>annotated
+        message</i> to mean the message as seen at the receiver.
+      </p>
+
+      <p>
+        An annotated message consists of the bare message plus areas for annotation at the head and
+        foot of the bare message. There are two classes of annotations: annotations that travel with
+        the message indefinitely, and annotations that are consumed by the next node.
+      </p>
+
+      <p>
+        The bare message is divided between standard properties and application data. The standard
+        properties have a defined format and semantics and are visible to the messaging
+        infrastructure. Application data may be AMQP formatted, opaque binary, or a combination of
+        both. AMQP formatted application data is visible to the messaging infrastructure for
+        additional services such as querying by filters.
+      </p>
+
+      <p>
+        Altogether the message consists of the following sections:
+      </p>
+
+      <ol>
+        <li>
+          <p>
+            Exactly one <xref name="header"/> section for annotations at the head of the message.
+          </p>
+        </li>
+        <li>
+          <p>
+            Exactly one <xref name="properties"/> section for standard properties in the bare
+            message.
+          </p>
+        </li>
+        <li>
+          <p>Zero or more application data sections.</p>
+        </li>
+        <li>
+          <p>
+            Exactly one <xref name="footer"/> section for annotations at the tail of the message.
+          </p>
+        </li>
+      </ol>
+
+      <picture><![CDATA[
+  Section 0   Section 1    Section 2         Section n-2   Section n-1
++-----------+------------+-----------+-----+-------------+-------------+
+|  header   | properties | app-data  | ... |  app-data   |   footer    |
++-----------+------------+-----------+-----+-------------+-------------+
+]]>
+      </picture>
+
+      <p>
+        Each message section MUST be distinguished and identified with a format-code as per the
+        Message Fragmentation definition in the <xref name="links"/> section of Book III. The format
+        codes are assigned according to <xref name="section-codes"/>.
+      </p>
+    </doc>
+
+    <type class="restricted" name="section-codes" source="uint">
+      <choice name="header" value="0">
+        <doc>
+          <p>
+            Section-code indicating a header section (one of which MUST form the first section of a
+            Message).  Sections of this type MUST be of zero length or consist of a single encoded
+            instance of the <xref name="header"/> type.
+          </p>
+        </doc>
+      </choice>
+      <choice name="properties" value="1">
+        <doc>
+          <p>
+            Section-code indicating a properties section (one of which MUST form the second section
+            of a Message).  Sections of this type MUST be of zero length or consist of a single
+            encoded instance of the <xref name="properties"/> type.
+          </p>
+        </doc>
+      </choice>
+      <choice name="footer" value="2">
+        <doc>
+          <p>
+            Section-code indicating a footer section (one of which MUST form the last section of a
+            Message).  Sections of this type MUST be of zero length or consist of a single encoded
+            instance of the <xref name="footer"/> type.
+          </p>
+        </doc>
+      </choice>
+      <choice name="map-data" value="3">
+        <doc>
+          <p>
+            Section-code indicating a application data section. Sections of this type MUST be of
+            zero length or consist of a single encoded instance of an AMQP the
+            <xref type="type" name="map"/>.
+          </p>
+        </doc>
+      </choice>
+      <choice name="list-data" value="4">
+        <doc>
+          <p>
+            Section-code indicating a application data section. Sections of this type MUST be of
+            zero length or consist of a single encoded instance of an AMQP the
+            <xref type="type" name="list"/>.
+          </p>
+        </doc>
+      </choice>
+      <choice name="data" value="5">
+        <doc>
+          <p>
+            Section-code indicating a application data section. Sections of this type consist of
+            opaque binary data (note, in particular, that the section is <b>not</b> an instance of
+            the AMQP <xref type="type" name="binary"/> type).
+          </p>
+        </doc>
+      </choice>
+    </type>
+
+    <type class="compound" name="header" label="transport headers for a Message">
+      <doc>
+        <p>
+          The header struct carries information about the transfer of a Message over a specific
+          Link.
+        </p>
+      </doc>
+
+      <descriptor name="amqp:header:list" code="0x00000001:0x0009801"/>
+
+      <field name="durable" type="boolean" label="specify durability requirements">
+        <doc>
+          <p>
+            Durable Messages MUST NOT be lost even if an intermediary is unexpectedly terminated and
+            restarted.
+          </p>
+        </doc>
+      </field>
+
+      <field name="priority" type="ubyte" label="relative Message priority">
+        <doc>
+          <p>
+            This field contains the relative Message priority. Higher numbers indicate higher
+            priority Messages. Messages with higher priorities MAY be delivered before those with
+            lower priorities.
+          </p>
+
+          <p>
+            An AMQP intermediary implementing distinct priority levels MUST do so in the following
+            manner:
+          </p>
+
+          <ul>
+            <li>
+              <p>
+                If n distinct priorities are implemented and n is less than 10 -- priorities 0 to
+                (5 - ceiling(n/2)) MUST be treated equivalently and MUST be the lowest effective
+                priority.  The priorities (4 + floor(n/2)) and above MUST be treated equivalently
+                and MUST be the highest effective priority. The priorities (5 - ceiling(n/2)) to (4
+                + floor(n/2)) inclusive MUST be treated as distinct priorities.
+              </p>
+            </li>
+
+            <li>
+              <p>
+                If n distinct priorities are implemented and n is 10 or greater -- priorities 0 to
+                (n - 1) MUST be distinct, and priorities n and above MUST be equivalent to priority
+                (n - 1).
+              </p>
+            </li>
+          </ul>
+
+          <p>
+            Thus, for example, if 2 distinct priorities are implemented, then levels 0 to 4 are
+            equivalent, and levels 5 to 9 are equivalent and levels 4 and 5 are distinct. If 3
+            distinct priorities are implements the 0 to 3 are equivalent, 5 to 9 are equivalent and
+            3, 4 and 5 are distinct.
+          </p>
+
+          <p>
+            This scheme ensures that if two priorities are distinct for a server which implements m
+            separate priority levels they are also distinct for a server which implements n
+            different priority levels where n &gt; m.
+          </p>
+        </doc>
+      </field>
+
+      <field name="transmit-time" type="timestamp" label="the time of Message transmit">
+        <doc>
+          <p>
+            The point in time at which the sender considers the Message to be transmitted. The ttl
+            field, if set by the sender, is relative to this point in time.
+          </p>
+        </doc>
+      </field>
+
+      <field name="ttl" type="ulong" label="time to live in ms">
+        <doc>
+          <p>
+            Duration in milliseconds for which the Message should be considered "live". If this is
+            set then a Message expiration time will be computed based on the transmit-time plus this
+            value. Messages that live longer than their expiration time will be discarded (or dead
+            lettered). If the transmit-time is not set, then the expiration is computed relative to
+            the Message arrival time.
+          </p>
+        </doc>
+      </field>
+
+      <field name="former-acquirers" type="uint" label="">
+        <doc>
+          <p>
+            The number of other DESTRUCTIVE Links to which delivery of this Message was previously
+            attempted unsuccessfully. This does not include the current Link even if delivery to the
+            current Link has been previously attempted.
+          </p>
+        </doc>
+      </field>
+
+      <field name="delivery-failures" type="uint"
+             label="the number of prior unsuccessful delivery attempts">
+        <doc>
+          <p>
+            The number of unsuccessful previous attempts to deliver this message. If this value is
+            non-zero it may be taken as an indication that the Message may be a duplicate. The
+            delivery-failures value is initially set to the same value as the Message has when it
+            arrived at the source.  It is incremented When:
+          </p>
+
+          <ol>
+            <li>
+              <p>
+                the Message has previously been sent from this Node using a Source with a
+                distribution-mode of DESTRUCTIVE which closed without the Message being acknowledged
+              </p>
+            </li>
+
+            <li>
+              <p>
+                the Message has previously been sent from this Node  using a Source with a
+                distribution-mode of DESTRUCTIVE and was subsequently finalized with a disposition
+                of <xref name="released"/> and the delivery-failed field set to true.
+              </p>
+            </li>
+          </ol>
+        </doc>
+      </field>
+
+      <field name="format-code" type="uint" label="indicates the format of the Message"/>
+
+      <field name="message-attrs" type="message-attributes" label="message attributes">
+        <doc>
+          <p>
+            The message-attrs map provides an extension point where domain or vendor specific
+            end-to-end attributes can be added to the Message header. As the Message (and therefore
+            the header) passes through a node, the values in the message-attrs map MUST be retained,
+            unless augmented or updated at the node. Further the message-attrs value can be
+            augmented or updated at each node either through node configuration, or through
+            explicit updates using the <xref type="type" name="disposition"/> command and
+            dispositions which allow for updates to the message-attrs.
+          </p>
+        </doc>
+      </field>
+
+      <field name="delivery-attrs" type="message-attributes" label="delivery attributes">
+        <doc>
+          <p>
+            The delivery-attrs map provides an extension point where domain or vendor specific
+            attributes related only to the current state of the Message at the source, or relating
+            to the current transfer to the target can be added to the Message header. The
+            delivery-attrs value can be augmented or updated at the node either through node
+            configuration, or through explicit updates using the
+            <xref type="type" name="disposition"/> command
+            and dispositions which allow for updates to the delivery-attrs.
+          </p>
+        </doc>
+      </field>
+
+    </type>
+
+    <type class="compound" name="properties" label="immutable properties of the Message">
+      <doc>
+        <p>Message properties carry information about the Message.</p>
+      </doc>
+
+      <descriptor name="amqp:properties:list" code="0x00000001:0x00009802"/>
+
+      <field name="message-id" type="binary" label="application Message identifier">
+        <doc>
+          <p>
+            Message-id is an optional property which uniquely identifies a Message within the
+            Message system. The Message producer is usually responsible for setting the message-id
+            in such a way that it is assured to be globally unique. The server MAY discard a Message
+            as a duplicate if the value of the message-id matches that of a previously received
+            Message sent to the same Node.
+          </p>
+        </doc>
+      </field>
+
+      <field name="user-id" type="binary" label="creating user id">
+        <doc>
+          <p>
+            The identity of the user responsible for producing the Message. The client sets this
+            value, and it MAY be authenticated by intermediaries.
+          </p>
+        </doc>
+      </field>
+
+      <!-- XXX: discuss type and fix docs if it really is a string -->
+      <field name="to" type="string" label="the name of the Node the Message is destined for">
+        <doc>
+          <p>
+            The to field identifies the Node that is the intended destination of the Message. On any
+            given transfer this may not be the Node at the receiving end of the Link.
+          </p>
+        </doc>
+      </field>
+
+      <!-- XXX: discuss type and fix docs if it really is a string -->
+      <field name="reply-to" type="string" label="the Node to send replies to">
+        <doc>
+          <p>The name of the Node to send replies to.</p>
+        </doc>
+      </field>
+
+      <field name="correlation-id" type="binary" label="application correlation identifier">
+        <doc>
+          <p>
+            This is a client-specific id that may be used to mark or identify Messages between
+            clients. The server ignores this field.
+          </p>
+        </doc>
+      </field>
+
+      <field name="content-length" type="ulong" label="length of the combined payload in bytes">
+        <doc>
+          <p>
+            The total size in octets of the combined payload of all transfer commands that together
+            make the Message.
+          </p>
+        </doc>
+      </field>
+
+      <field name="content-type" type="symbol" label="MIME content type">
+        <doc>
+          <p>
+            The RFC-2046 MIME type for the Message content (such as "text/plain"). This is set by
+            the originating client. As per RFC-2046 this may contain a charset parameter defining
+            the character encoding used: e.g. 'text/plain; charset="utf-8"'.
+          </p>
+        </doc>
+      </field>
+
+    </type>
+
+    <type class="compound" name="footer" label="transport footers for a Message">
+
+      <descriptor name="amqp:footer:list" code="0x00000001:0x00009803"/>
+
+      <field name="message-attrs" type="message-attributes" label="message attributes">
+        <doc>
+          <p>
+            The message-attrs map provides an extension point where domain or vendor specific
+            end-to-end attributes can be added to the Message footer. As the Message (and therefore
+            the header) passes through a node, the values in the message-attrs map MUST be retained,
+            unless augmented or updated at the node. Further the message-attrs value can be
+            augmented or updated at each node either through node configuration, or through
+            explicit updates using the <xref type="type" name="disposition"/> command and
+            dispositions which allow for updates to the message-attrs.
+          </p>
+        </doc>
+      </field>
+
+      <field name="delivery-attrs" type="message-attributes" label="delivery attributes">
+        <doc>
+          <p>
+            The delivery-attrs map provides an extension point where domain or vendor specific
+            attributes related only to the current state of the Message at the source, or relating
+            to the current transfer to the target can be added to the Message footer. The
+            delivery-attrs value can be augmented or updated at the node either through node
+            configuration, or through explicit updates using the
+            <xref type="type" name="disposition"/> command and dispositions which allow for updates
+            to the delivery-attrs.
+          </p>
+        </doc>
+      </field>
+    </type>
+
+    <type class="restricted" name="message-attributes" source="map">
+      <doc>
+        <p>
+          A map providing an extension point by which annotations on message deliveries. All values
+          used as keys in the map MUST be of type symbol. Further if a key begins with the string
+          "x-req-" then the target MUST reject the message unless it understands how to process the
+          supplied key/value.
+        </p>
+      </doc>
+    </type>
+
+  </section>
+
+  <section name="transfer-dispositions" title="Transfer Dispositions"
+           label="definitions for transfer dispositions">
+
+    <doc title="Message State on a Node">
+      <p>
+        The Messaging layer defines a precise set of states for Messages on a Node. The transitions
+        between these states are controlled by the transfer of Messages from a Node and the
+        disposition communicated back.  Note that the state of a Message on one Node does not affect
+        the state of the same Message at a separate Node.
+      </p>
+      <p>
+        By default a Message will begin in the AVAILABLE state. If the Message begins transferring
+        over a <i>destructive</i> Link, the Message will transition to the ACQUIRED state - thus
+        becoming ineligible for transfer to other Links with a default configuration.
+      </p>
+      <p>
+        A Message will remain ACQUIRED at the sending node until the disposition is <i>settled</i>,
+        or until the transfer is aborted.  A transfer aborted due to the destruction of the
+        underlying Link will cause the Message to transition according to the disposition configured
+        as the <i>orphan-disposition</i> on the source.
+      </p>
+      <p>
+        If the transfer occurs on a Session configured in a transaction mode (i.e. with a
+        <i>txn-mode</i> of <i>local</i>, <i>distributed</i> or <i>promotable</i>) then the
+        disposition is not settled until the transaction has been committed. If a transaction fails
+        to commit (either through an explicit failure or rollback, or through the destruction of the
+        Session without a commit having occurred) then all unsettled transfers are irreversibly
+        assigned the released disposition.
+      </p>
+      <picture title="Message State Transitions"><![CDATA[
+               +------------+
+            +->| AVAILABLE  |
+            |  +------------+
+            |        |
+DISPOSITION |        | S:TRANSFER
+(RELEASED)  |        |
+            |        |
+            |        |
+            |        |
+            |       \|/
+            |  +------------+
+            +--|  ACQUIRED  |
+               +------------+
+                     |
+                     |
+                     |
+                     | DISPOSITION(COMPLETE)
+                     |
+                     |
+                    \|/
+               +------------+
+               |  ARCHIVED  |
+               +------------+
+]]>
+      </picture>
+      <p>
+        State transitions may also occur spontaneously at the Node. For example if a Message with
+        ttl set may expire, and the effect of expiry may be (depending on Node configuration) to
+        move spontaneously from the AVAILABLE state into the ARCHIVED state.
+      </p>
+    </doc>
+
+
+    <type class="restricted" name="message-state" source="ubyte">
+      <doc>
+        <p>
+          An enumeration of the defined states of a Message on a Node.
+        </p>
+      </doc>
+
+      <choice name="available" value="0">
+        <doc>
+          <p>
+            The AVAILABLE state.
+          </p>
+        </doc>
+      </choice>
+      <choice name="acquired" value="1">
+        <doc>
+          <p>
+            The ACQUIRED state.
+          </p>
+        </doc>
+      </choice>
+      <choice name="archived" value="2">
+        <doc>
+          <p>
+            The ARCHIVED state.
+          </p>
+        </doc>
+      </choice>
+    </type>
+
+    <doc title="Dispositions">
+      <p>
+        The Messaging layer defines a concrete set of dispositions which can be used in the
+        <xref type="type" name="disposition"/> command:
+      </p>
+      <ul>
+        <li>
+          <p><b>released</b></p>
+        </li>
+        <li>
+          <p><b>rejected</b></p>
+        </li>
+        <li>
+          <p><b>completed</b></p>
+        </li>
+
+      </ul>
+    </doc>
+
+    <type class="compound" name="released" label="the released disposition">
+      <doc>
+        <p>
+          The released disposition is used to indicate that a given transfer was not and will not be
+          acted upon. The Messages carried by released transfers transition to the available state.
+          Messages that have been released MAY subsequently be delivered out of order.
+          Implementations SHOULD ensure that released Messages keep their position with respect to
+          undelivered Messages of the same priority.
+        </p>
+      </doc>
+
+      <descriptor name="amqp:released:map" code="0x00000001:0x00009804"/>
+
+      <field name="truncate" type="boolean" label="permit truncation of the remaining transfer">
+        <doc>
+          <p>
+            The truncate flag, if true, indicates that the receiver is not interested in the rest of
+            the Message content, and the sender is free to omit it.
+          </p>
+        </doc>
+      </field>
+
+      <field name="delivery-failed" type="boolean"
+             label="count the transfer as an unsuccessful delivery attempt">
+        <doc>
+          <p>
+            If the delivery-failed flag is set, any Messages released MUST have their
+            delivery-failures count incremented.
+          </p>
+        </doc>
+      </field>
+
+      <field name="deliver-elsewhere" type="boolean" label="prevent redelivery">
+        <doc>
+          <p>
+            If the deliver-elsewhere is set, then any Messages released MUST NOT be redelivered to
+            the releasing Link Endpoint.
+          </p>
+        </doc>
+      </field>
+
+      <field name="message-attrs" type="message-attributes" label="message attributes">
+        <doc>
+          <p>
+            Map containing attributes to combine with the existing <i>message-attrs</i> held in the
+            Message's header section.  Where the existing message-attrs of the Message contain an
+            entry with the same key as an entry in this field, the value in this field associated
+            with that key replaces the one in the existing headers; where the existing message-attrs
+            has no such value, the value in this map is added.
+          </p>
+        </doc>
+      </field>
+
+      <field name="delivery-attrs" type="message-attributes" label="delivery attributes">
+        <doc>
+          <p>
+            Map containing attributes to combine with the existing <i>delivery-attrs</i> held in the
+            Message's header section.  Where the existing delivery-attrs of the Message contain an
+            entry with the same key as an entry in this field, the value in this field associated
+            with that key replaces the one in the existing headers; where the existing
+            delivery-attrs has no such value, the value in this map is added.
+          </p>
+        </doc>
+      </field>
+
+    </type>
+
+    <type class="compound" name="rejected" label="the rejected disposition">
+      <doc>
+        <p>
+          The rejected disposition is used to indicate that an incoming Message is invalid and
+          therefore unprocessable. If an attempt to transfer a Message results in a reject from the
+          recipient, the sender MUST add the supplied reject-properties to the Message header
+          message-attrs. A rejected Message may be held at the node, forwarded to a different node
+          (for instance a dead letter queue) or discarded depending on configuration at the node.
+        </p>
+      </doc>
+
+      <descriptor name="amqp:rejected:map" code="0x00000001:0x00009805"/>
+
+      <field name="truncate" type="boolean" label="permit truncation of the remaining transfer">
+        <doc>
+          <p>
+            The truncate flag, if true, indicates that the receiver is not interested in the rest of
+            the Message content, and the sender is free to omit it.
+          </p>
+        </doc>
+      </field>
+
+      <field name="reject-properties" type="map">
+        <doc>
+          <p>
+            The map supplied in this field will be placed in any rejected Message headers in the
+            message-attrs map under the key "reject-properties".
+          </p>
+        </doc>
+      </field>
+    </type>
+
+    <type class="compound" name="completed"  label="the completed disposition">
+      <doc>
+        <p>
+          The completed disposition is used to indicate that the Message has been processed at this
+          time, and can be moved to the ARCHIVED state. For a destructive link this is the default
+          presumptive disposition.
+        </p>
+      </doc>
+
+      <descriptor name="amqp:completed:map" code="0x00000001:0x00009806"/>
+
+      <field name="truncate" type="boolean" label="permit truncation of the remaining transfer">
+        <doc>
+          <p>
+            The truncate flag, if true, indicates that the receiver is not interested in the rest of
+            the Message content, and the sender is free to omit it.
+          </p>
+        </doc>
+      </field>
+
+    </type>
+
+  </section>
+
+
+  <section name="addressing" title="Sources and Targets">
+
+    <doc>
+      <p>
+        Concrete types <xref type="type" name="source"/> and <xref type="type" name="target"/> are
+        defined to be used in the <i>source</i> and <i>target</i> fields of the
+        <xref type="type" name="link"/> command respectively. The <xref type="type" name="source"/>
+        is comprised of an address (which the container of the outgoing Link Endpoint will resolve
+        to a Node within that container) coupled with properties which determine:
+      </p>
+      <ul>
+        <li>
+          <p>
+            which messages from the sending Node will be sent on the Link,
+          </p>
+        </li>
+        <li>
+          <p>
+            how sending the message affects the state of that message at the sending Node,
+          </p>
+        </li>
+        <li>
+          <p>
+            the length of time that the source will retain state following the destruction of the
+            Link with which it was last associated, and
+          </p>
+        </li>
+        <li>
+          <p>
+            the behaviour of Messages which have been transferred on the Link, but whose fate has
+            not yet been settled, when the source is destroyed.
+          </p>
+        </li>
+      </ul>
+
+    </doc>
+    <doc title="Distribution Modes">
+      <p>
+        The Source defines a distribution-mode. There are two defined distribution-modes:
+        <i>destructive</i> and <i>non-destructive</i>. The distribution-mode has two related effects
+        on the behaviour of the source.
+      </p>
+      <ol>
+        <li>
+          <p>
+            The <i>destructive</i> distribution-mode causes messages transferred from the node to
+            transition to the ACQUIRED state as they enter the source. The <i>non-destructive</i>
+            distribution-mode leaves the state of the Message unchanged on the Node.
+          </p>
+        </li>
+        <li>
+          <p>
+            The <i>destructive</i> distribution-mode allows messages transferred from the node to
+            have their further state transitions affected by the presumptive disposition which may
+            be altered using the <xref type="type" name="disposition"/> command. The
+            <xref type="type" name="disposition"/> command has no effect on Messages transferred
+            from a Source with a <i>non-destructive</i> distribution-mode.
+          </p>
+        </li>
+      </ol>
+      <p>
+        The distribution-mode of a Source determines how Messages from a Node are distributed among
+        its associated Sources. Messages from a Node MAY be distributed to all associated Sources
+        with a NON-DESTRUCTIVE distribution-mode, but to at most one associated Link with a
+        DESTRUCTIVE distribution mode.
+      </p>
+    </doc>
+    <doc title="Filtering Messages">
+      <p>
+        The Source has properties which control which messages from the Node enter the Link
+        associated with the Source. Firstly the source controls the set of potentially transferrable
+        Messages by restricting entry to the link based on the state of the Message at the source
+        node. By default, only Messages in the AVAILABLE state at the node are eligible for
+        transfer.
+      </p>
+      <p>
+        Secondly the source may be further restricted by the addition of a <i>filter</i>.  Filters
+        can be thought of as functions which take the message as input and return a boolean value:
+        true if the message will be accepted by the source, false otherwise. A <i>filter</i>
+        MUST NOT change its return value for a Message unless the state or annotations on the
+        Message at the Node change (e.g. through an updated disposition).
+      </p>
+      <p>
+        Finally the Source MUST NOT resend a Message which has previously been successfully
+        transferred from the Source, and been settled to a COMPLETED disposition. For a
+        <i>destructive</i> source with a default configuration this is trivially achieved as such an
+        end result will lead to the Message in the ARCHIVED state on the Node, and thus anyway
+        ineligible for transfer. For a <i>non-destructive</i> state must be retained at the source
+        to ensure compliance. In practice, for nodes which maintain a strict order on Messages at
+        the node, the state may simply be a record of the most recent Message transferred.
+      </p>
+
+    </doc>
+      <!-- XXX: update this stuff-->
+      <!-- TODO
+    <doc>
+
+
+      <p>
+        If the name refers to an existing Link within the defined scope (either container or
+        Session), and the source and target are either not present or match the source and target of
+        the existing Link, then the Link end is updated to match the desired state specified in the
+        <xref name="link"/> command. If the source and target do <b>not</b> match the source and
+        target of the existing Link, then the old Link end is destroyed and a new Link end is
+        created in accordance with the <xref name="link"/> command.
+      </p>
+    </doc>
+    -->
+
+    <type class="compound" name="source">
+      <descriptor name="amqp:source:map" code="0x00000001:0x00009701"/>
+
+      <field name="address" type="address" label="the address of the source">
+        <exception name="address-not-found" error-code="not-found"/>
+        <doc>
+          <p>
+            The address is resolved to a Node in the Container of the sending Link Endpoint.
+          </p>
+          <p>
+            The address of the source MUST be set when sent on a <xref type="type" name="link"/>
+            command sent by the sending Link Endpoint. When sent by the receiving Link Endpoint the
+            address MUST be set unless the create flag is set, in which case the address MUST NOT be
+            set.
+          </p>
+        </doc>
+      </field>
+
+      <!-- XXX: this should be shared with target somehow -->
+      <field name="create" type="boolean" label="request creation of a remote Node">
+        <doc>
+          <p>
+            The create flag, if set, indicates that the local peer would like the remote peer to
+            generate a unique address. The remote peer will supply the generated address in source
+            field of the corresponding <xref type="type" name="link"/> command. If the create flag
+            is set, the source address MUST be null. The generated Node will exist until the Source
+            is destroyed. The create flag MUST NOT be set on the source carried by the
+            <xref type="type" name="link"/> sent by the outgoing Link Endpoint.
+            <!-- FIXME : lifetime of created Source -->
+          </p>
+
+          <p>
+            The algorithm used to produce the address from the Link name, must produce repeatable
+            results. If the Link is durable, generating an address from a given Link name within a
+            given client-id MUST always produce the same result. If the Link is not durable,
+            generating an address from a given Link name within a given Session MUST always produce
+            the same result. The generated address SHOULD include the Link name and Session-name or
+            client-id in some recognizable form for ease of traceability.
+          </p>
+        </doc>
+      </field>
+
+      <!-- XXX: this should be shared with target somehow -->
+      <field name="timeout" type="uint" label="the source timeout">
+        <doc>
+          <p>
+            The minimum length of time (in milliseconds) after the Session has been destroyed before
+            the source is destroyed. The value set by the receiving Link endpoint is indicative of
+            the timeout it desires, the value set by the sending Link endpoint defines the timeout
+            which will be used.
+          </p>
+        </doc>
+      </field>
+
+      <field name="distribution-mode" type="distribution-mode"
+             label="the distribution mode of the Link">
+        <doc>
+          <p>
+            This field MUST be set by the sending end of the Link. This field MAY be set by the
+            receiving end of the Link to indicate a preference when a Node supports multiple
+            distribution modes.  The <xref type="type" name="disposition"/> command has no effect on
+            messages sent over a <i>non-destructive</i> Link.
+          </p>
+        </doc>
+      </field>
+
+      <field name="filter" type="filter-set"
+             label="a set of predicate to filter the Messages admitted onto the Link" />
+
+      <field name="message-states" type="message-state" multiple="true"
+             label="states of messages to be considered for sending from the source">
+        <doc>
+          <p>
+            Indicates the Message states that may be transferred over this Link. If no values are
+            set by the receiver, the sender MUST set this to <i>available</i>; otherwise the
+            sender MUST send only messages in states that are in both the sender's and receiver's
+            <i>message-states</i> values.  Sources with distribution-mode of <i>destructive</i>
+            may only send messages in the <i>available</i> state.
+          </p>
+        </doc>
+      </field>
+
+      <field name="orphan-disposition" type="map" label="disposition for unacked Messages">
+        <doc>
+          <p>
+            Indicates the disposition to be used for Messages that are acquired but not acknowledged
+            when the Link is destroyed and it is no longer possible to acknowledge any of the
+            outstanding Messages, e.g. the Session is also destroyed.  The value must be a valid
+            disposition (e.g. a <xref name="released"/>, or <xref name="rejected"/> value).
+          </p>
+        </doc>
+      </field>
+
+    </type>
+
+    <type class="compound" name="target">
+
+      <descriptor name="amqp:target:map" code="0x00000001:0x00009702"/>
+
+      <field name="address" type="address" label="The address of the target.">
+        <exception name="address-not-found" error-code="not-found"/>
+        <doc>
+          <p>
+            The address is resolved to a Node by the Container of the receiving Link Endpoint.
+          </p>
+          <p>
+            The address of the target MUST be set when sent on a <xref type="type" name="link"/>
+            command sent by the receiving Link Endpoint. When sent by the sending Link Endpoint the
+            address MUST be set unless the create flag is set, in which case the address MUST NOT be
+            set.
+          </p>
+        </doc>
+      </field>
+
+      <field name="create" type="boolean" label="request creation of a remote Node">
+        <doc>
+          <p>
+            The create flag, if set, indicates that the local peer would like the remote peer to
+            generate a unique address. The remote peer will supply the generated address in target
+            field of the corresponding <xref type="type" name="link"/> command. If the create flag
+            is set, the target address MUST be null. The generated Node will exist until the Link is
+            destroyed.  The create flag MUST NOT be set on the target carried by the
+            <xref type="type" name="link"/> sent by the incoming Link Endpoint.
+            <!-- FIXME : lifetime of created Target -->
+          </p>
+
+          <p>
+            The algorithm used to produce the address from the Link name, must produce repeatable
+            results. If the Link is durable, generating an address from a given Link name within a
+            given client-id MUST always produce the same result. If the Link is not durable,
+            generating an address from a given Link name within a given Session MUST always produce
+            the same result. The generated address SHOULD include the Link name and Session-name or
+            client-id in some recognizable form for ease of traceability.
+          </p>
+        </doc>
+      </field>
+
+      <!-- XXX: this should be shared with source somehow -->
+      <field name="timeout" type="uint" label="the target timeout">
+        <doc>
+          <p>
+            The minimum length of time (in milliseconds) after the Link has been destroyed before
+            the target is destroyed. The value set by the sending Link endpoint is indicative of
+            the timeout it desires, the value set by the receiving Link endpoint defines the timeout
+            which will be used.
+          </p>
+        </doc>
+      </field>
+
+    </type>
+
+    <type class="restricted" name="address" source="binary"
+          label="name of the source or target for a Message">
+      <doc>
+        <p>
+          Specifies the name for a source or target to which Messages are to be transferred to or
+          from. Addresses are expected to be human readable, but are intentionally considered
+          opaque. The format of an address is not defined by this specification.
+        </p>
+      </doc>
+    </type>
+
+    <type class="restricted" name="distribution-mode" source="uint"
+          label="Link distribution policy">
+      <doc>
+        <p>
+          Policies for distributing Messages when multiple Links are connected to the same Node.
+        </p>
+      </doc>
+
+      <choice name="destructive" value="1">
+        <doc>
+          <p>
+            once successfully transferred over the Link, the Message will no longer be available to
+            other Links from the same Node
+          </p>
+        </doc>
+      </choice>
+
+      <choice name="non-destructive" value="2">
+        <doc>
+          <p>
+            once successfully transferred over the Link, the Message is still available for other
+            Links from the same Node
+          </p>
+        </doc>
+      </choice>
+    </type>
+
+    <type class="compound" name="filter"
+          label="the predicate to filter the Messages admitted onto the Link">
+
+      <descriptor name="amqp:filter:list" code="0x00000001:0x00009703"/>
+
+      <field name="filter-type" type="symbol" required="true" label="the type of the filter" />
+      <field name="filter" type="*" required="true"
+             label="the filter predicate" />
+
+    </type>
+
+    <type class="restricted" name="filter-set" source="map">
+      <doc>
+        <p>
+          A set of named filters.  Every key in the map must be of type
+          <xref type="type" name="symbol"/>, every value must be of type
+          <xref type="type" name="filter"/>.  A message will pass through a filter-set if and only
+          if it passes through each of the named filters
+        </p>
+      </doc>
+    </type>
+
+  </section>
+
+</amqp>



Mime
View raw message