FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS
FIPA ACL Message Representation
in XML Specification
|
Document title |
FIPA ACL Message Representation in XML Specification |
||
|
Document number |
XC00071D |
Document source |
FIPA TC Agent Management |
|
Document status |
Experimental |
Date of this status |
2002/11/01 |
|
Supersedes |
FIPA00024 |
||
|
Contact |
fab@fipa.org |
||
|
Change history |
See Informative Annex A — ChangeLog |
||
©
1996-2002 Foundation for Intelligent Physical Agents
http://www.fipa.org/
Geneva, Switzerland
|
Notice |
|
Use of the technologies described in this specification may infringe patents, copyrights or other intellectual property rights of FIPA Members and non-members. Nothing in this specification should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights. FIPA strongly encourages anyone implementing any part of this specification to determine first whether part(s) sought to be implemented are covered by the intellectual property of others, and, if so, to obtain appropriate licenses or other permission from the holder(s) of such intellectual property prior to implementation. This specification is subject to change without notice. Neither FIPA nor any of its Members accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from the use of this specification. |
Foreword
The Foundation for Intelligent Physical Agents (FIPA) is an international organization that is dedicated to promoting the industry of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. This occurs through open collaboration among its member organizations, which are companies and universities that are active in the field of agents. FIPA makes the results of its activities available to all interested parties and intends to contribute its results to the appropriate formal standards bodies where appropriate.
The members of FIPA are individually and collectively committed to open competition in the development of agent-based applications, services and equipment. Membership in FIPA is open to any corporation and individual firm, partnership, governmental body or international organization without restriction. In particular, members are not bound to implement or use specific agent-based standards, recommendations and FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are developed through direct involvement of the FIPA membership. The status of a specification can be either Preliminary, Experimental, Standard, Deprecated or Obsolete. More detail about the process of specification may be found in the FIPA Document Policy [f-out-00000] and the FIPA Specifications Policy [f-out-00003]. A complete overview of the FIPA specifications and their current status may be found on the FIPA Web site.
FIPA is a non-profit association registered in Geneva, Switzerland. As of June 2002, the 56 members of FIPA represented many countries worldwide. Further information about FIPA as an organization, membership information, FIPA specifications and upcoming meetings may be found on the FIPA Web site at http://www.fipa.org/.
Contents
This document deals with message transportation between inter-operating agents and also forms part of the FIPA Agent Management Specification [FIPA00023]. It contains specifications for:
· Syntactic representation of ACL in XML form (see [W3Cxml]).
This document defines the message transport syntax for an XML based representation of ACL. It should be noted that some grammatical information is expressed in the comments of the DTD. These additions are normative aspects of the definition even though they are not checked by the XML parser.
The name assigned to this component is:
fipa.acl.rep.xml.std
<!-- Document Type: XML DTD
Document Purpose: Encoding of FIPA ACL messages in XML
(see [FIPA00067]) and http://www.fipa.org/)
Last Revised: 2002/05/10 -->
<!-- Possible FIPA Communicative Acts. See [FIPA00037] for a
full list of valid performatives. -->
<!ENTITY %communicative-acts "accept-proposal
| agree
| cancel
| cfp
| confirm
| disconfirm
| failure
| inform
| not-understood
| propose
| query-if
| query-ref
| refuse
| reject-proposal
| request
| request-when
| request-whenever
| subscribe
| inform-if
| inform-ref
| proxy
| propagate">
<!-- The FIPA message root element, the communicative act is
an attribute - see below and the message itself is a list
of parameters. The list is unordered. None of the elements
should occur more than once except receiver. -->
<!ENTITY %msg-param "receiver
| sender
| content
| language
| encoding
| ontology
| protocol
| reply-with
| in-reply-to
| reply-by
| reply-to
| conversation-id
| user-defined">
<!ELEMENT fipa-message ( %msg-param; )*>
<!-- Attribute for the fipa-message - the communicative act itself and
the conversation id (which is here so an ID value can be used). -->
<!ATTLIST fipa-message act ( %communicative-acts; ) #REQUIRED
conversation-id ID #IMPLIED>
<!ELEMENT sender ( agent-identifier )>
<!ELEMENT receiver ( agent-identifier+ )>
<!-- The message content.
One can choose to embed the actual content in the message,
or alternatively refer to a URI which represents this content. -->
<!ELEMENT content ( #PCDATA )>
<!ATTLIST content href CDATA #IMPLIED>
<!-- The content language used for the content.
The linking attribute href associated with language can be used
to refer in an unambiguous way to the (formal) definition of the
standard/fipa content language. -->
<!ELEMENT language ( #PCDATA )>
<!ATTLIST language href CDATA #IMPLIED>
<!-- The encoding used for the content language.
The linking attribute href associated with encoding can be used
to refer in an unambiguous way to the (formal) definition of the
language encoding. -->
<!ELEMENT encoding ( #PCDATA )>
<!ATTLIST encoding href CDATA #IMPLIED>
<!-- The ontology used in the content.
The linking attribute href associated with ontology can be used
to refer in an unambiguous way to the (formal) definition of the
ontology. -->
<!ELEMENT ontology ( #PCDATA )>
<!ATTLIST ontology href CDATA #IMPLIED>
<!-- The protocol element.
The linking attribute href associated with protocol can be used
to refer in an unambiguous way to the (formal) definition of the
protocol. -->
<!ELEMENT protocol ( #PCDATA )>
<!ATTLIST protocol href CDATA #IMPLIED>
<!ELEMENT reply-with ( #PCDATA )>
<!ATTLIST reply-with href CDATA #IMPLIED>
<!ELEMENT in-reply-to ( #PCDATA )>
<!ATTLIST in-reply-to href CDATA #IMPLIED>
<!ELEMENT reply-by EMPTY>
<!ATTLIST reply-by time CDATA #REQUIRED
href CDATA #IMPLIED>
<!ELEMENT reply-to ( agent-identifier+ )>
<!ELEMENT conversation-id ( #PCDATA )>
<!ATTLIST conversation-id href CDATA #IMPLIED>
<!ELEMENT agent-identifier ( name,
addresses?,
resolvers?,
user-defined* )>
<!ELEMENT name EMPTY>
<!-- An id can be used to uniquely identify the name of the agent.
The refid attribute can be used to refer to an already defined
agent name, avoiding unnecessary repetition. Either the id
OR refid should be specified, (both should not be present at the
same time). -->
<!ATTLIST name id ID #IMPLIED
refid IDREF #IMPLIED>
<!ELEMENT addresses ( url+ )>
<!ELEMENT url EMPTY>
<!ATTLIST url href CDATA #IMPLIED>
<!ELEMENT resolvers ( agent-identifier+ )>
<!ELEMENT user-defined ( #PCDATA )>
<!ATTLIST user-defined href CDATA #IMPLIED>
[FIPA00023] FIPA Agent Management Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00023/
[FIPA00037] FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00037/
[FIPA00067] FIPA Agent Message Transport Service Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00067/
[W3Cxml] Extensible Mark-up
Language (XML) 1.0 Recommendation. World Wide Web Consortium, 1998.
http://www.w3c.org/TR/REC-xml
Page 2, line 63: Improved readability of the XML
Page 2, line 86: Extended the msg-params definition to allow user-defined fields
Page 2, line 104: Changed the cardinality of receiver definition to one or more (+)
Page 3, line 166: Changed the cardinality of reply-to definition to one or more (+)