[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hyades-dev] More XML choices
|
Each of Andy's examples uses an XML style where each parameter is its own
element, and the value of the parameter is held in the "content" part of
the element. I think maybe we can be more streamlined than that. What
about this?
<command
header="1"
dest="101"
source="100"
session="1"
context="1001">
<agentMgr_registerAgent id="100" pid="4067" name="
org.eclipse.hyades.processControllerAgent"/>
</command>
The important parts of this example are:
1. The command you want to perform is separate from the routing
information. This is like the first of Andy's examples but unlike the
rest.
2. The "interface id" and "command id" are string values, not
numbers. Together, separated by an underscore, they form the inner element
name.
3. The parameters are all attributes of the command element. This
is more compact then <agentID>100</agentID>.
I think this style for commands and parameters is well-suited to the usual
kind of command, which has flat set of parameters. It's not well suited
for those commands or responses that contain structured data: a list of
processes, or a tree that describes variable grouping.
What do you think?
-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM
"Kaylor, Andrew" <andrew.kaylor@xxxxxxxxx>
Sent by: hyades-dev-admin@xxxxxxxxxxx
10/14/2004 04:15 PM
Please respond to
hyades-dev
To
<hyades-dev@xxxxxxxxxxx>
cc
Subject
[hyades-dev] More XML choices
As discussed in this morning's meeting, here are a few possibilities for
XML encoding of the HCE protocol. Obviously, we can mix and match things
we like about each group.
What do you think?
--------------------------------------------------
Option 1: Heavily SOAP influenced
--------------------------------------------------
This is basically what I sent out yesterday. The command header is
represented as an element with attributes, and the command itself is a
single element within the command header. The command uses an XML
namespace to fill the role of identifying the interface.
The primary advantage of this representation is that if you strip off the
command header your left with something that is exactly SOAP-compatible.
Thus, it is a known solution that will be familiar to those who know SOAP.
On the other hand, it is a bit verbose.
Definition
-----------
<xsd:complexType name="CommandType">
<xsd:sequence>
<xsd:any minOccurs="1" maxOccurs="1">
</xsd:sequence>
<xsd:attribute name="headerID" type="xsd:int">
<xsd:attribute name="destination" type="xsd:int">
<xsd:attribute name="source" type="xsd:int">
<xsd:attribute name="session" type="xsd:int">
<xsd:attribute name="context" type="xsd:int">
</xsdComplexType>
<xsd:complexType name="RegisterAgentType">
<xsd:element name="agentID" type="xsd:int>
<xsd:element name="processID" type="xsd:int>
<xsd:element name="agentName" type="xsd:string>
</xsd:complexType>
Example
-----------
<Command
headerID="1"
destination="101"
source="100"
session="1"
context="10001">
<agentMgr:registerAgent
xmlns:agentMgr="org.eclipse.hyades.agentMgr">
<agentID>100</agentID>
<processID>4067</processID>
<agentName>org.eclipse.hyades.processControllerAgent</agentName>
</agentMgr:registerAgent>
</Command>
--------------------------------------------------
Option 2: Interface and command IDs as attributes
--------------------------------------------------
This second variation moves the command ID and interface ID into the
command header (as pure IDs, no longer names). The command header then
contains a standardized element, parameters. The contents of the
"parameters" element are command-specific, and continue to use standard
XML Schema type definitions.
Definition
-----------
<xsd:complexType name="CommandType">
<xsd:sequence>
<xsd:element name="parameters" type="ParamListType"
minOccurs="1" maxOccurs="1">
</xsd:sequence>
<xsd:attribute name="headerID" type="xsd:int">
<xsd:attribute name="destination" type="xsd:int">
<xsd:attribute name="source" type="xsd:int">
<xsd:attribute name="session" type="xsd:int">
<xsd:attribute name="context" type="xsd:int">
<xsd:attribute name="interfaceID" type="xsd:int">
<xsd:attribute name="comandID" type="xsd:int">
</xsdComplexType>
<xsd:complexType name="ParamListType">
<xsd:any minOccurs="0" maxOccurs="unbound">
</xsd:complexType>
Example
-----------
<Command
headerID="1"
destination="101"
source="100"
session="1"
context="10001"
interfaceID="1001"
commandID="1">
<parameters>
<agentID>100</agentID>
<processID>4067</processID>
<agentName>org.eclipse.hyades.processControllerAgent</agentName>
</parameters>
</Command>
--------------------------------------------------
Option 3: Element-oriented command header
--------------------------------------------------
This option moves the command header members into the position of elements
rather than attributes of the command element. This adds some flexibility
in the command header format.
Definition
-----------
<xsd:complexType name="CommandType">
<xsd:sequence>
<xsd:element name="headerID" type="xsd:int">
<xsd:element name="destination" type="xsd:int">
<xsd:element name="source" type="xsd:int">
<xsd:element name="session" type="xsd:int">
<xsd:element name="context" type="xsd:int">
<xsd:element name="interfaceID" type="xsd:int">
<xsd:element name="comandID" type="xsd:int">
<xsd:element name="parameters" type="ParamListType"
minOccurs="1" maxOccurs="1">
</xsd:sequence>
</xsdComplexType>
<xsd:complexType name="ParamListType">
<xsd:any minOccurs="0" maxOccurs="unbound">
</xsd:complexType>
Example
-----------
<Command
<headerID>1<headerID>
<destination>101<destination>
<source>100<source>
<session>1<session>
<context>10001<context>
<interfaceID>1001<interfaceID>
<commandID>1<commandID>
<parameters>
<agentID>100</agentID>
<processID>4067</processID>
<agentName>org.eclipse.hyades.processControllerAgent</agentName>
</parameters>
</Command>
--------------------------------------------------
Option 4: Short names
--------------------------------------------------
Finally, this option follows the format in Option 3 (though it could be
done with any of the above options) but shortens all the names to reduce
the size of the data on the wire. The tradeoff is that it becomes
significantly less human-readable.
Definition
-----------
<xsd:complexType name="CommandType">
<xsd:sequence>
<xsd:element name="HID" type="xsd:int">
<xsd:element name="dest" type="xsd:int">
<xsd:element name="src" type="xsd:int">
<xsd:element name="ses" type="xsd:int">
<xsd:element name="ctxt" type="xsd:int">
<xsd:element name="IID" type="xsd:int">
<xsd:element name="CID" type="xsd:int">
<xsd:element name="parms" type="ParamListType" minOccurs="1"
maxOccurs="1">
</xsd:sequence>
</xsdComplexType>
<xsd:complexType name="ParamListType">
<xsd:any minOccurs="0" maxOccurs="unbound">
</xsd:complexType>
Example
-----------
<Command
<HID>1</HID>
<dest>101</dest>
<src>100</src>
<sess>1</sess>
<ctxt>10001</ctxt>
<IID>1001</IID>
<CID>1</CID>
<parms>
<AID>100</AID>
<PID>4067</PID>
<name>org.eclipse.hyades.processControllerAgent</name>
</parms>
</Command>
