FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 

 

FIPA ACL Message Representation
in XML Specification

 

Document title

FIPA ACL Message Representation in XML Specification

Document number

SC00071E

Document source

FIPA TC Agent Management

Document status

Standard

Date of this status

2002/12/03

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

1     Scope. 1

2     XML ACL Representation. 2

2.1      Component Name. 2

2.2      Syntax. 2

3     References. 5

4     Informative Annex A — ChangeLog. 6

4.1      2002/11/01 - version D by TC X2S. 6

4.2      2002/12/03 - version E by FIPA Architecture Board. 6


1         Scope

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]).

 


2         XML ACL Representation

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.

 

2.1        Component Name

The name assigned to this component is:

 

fipa.acl.rep.xml.std

 

2.2        Syntax

<!-- 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>

 


3         References

[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

 


4         Informative Annex A — ChangeLog

4.1        2002/11/01 - version D by TC X2S

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 (+)

 

4.2        2002/12/03 - version E by FIPA Architecture Board

Entire document:              Promoted to Standard status