---      LITE XML FORMAT DEFINITION  ----

ABSTRACT:  The text below is the basic definition of a lightweight xml-based client/server data exchange protocol.
It supports simple arrays, Unicode and basic type coercion while still keeping a very small footprint whenever possible.
This protocol is mostly structured around the idea of 'remote object manipulation' as opposed to 'remote method calls'.

AUTHOR: Jay Araujo
   


          A - FORMAT DESCRIPTION



A.1. CLIENT MESSAGES

a.1.1. Client messages that request for data (GET ACTION) are issued using a <c g="object.attribute" p="modifier" /> where:

         (c) -->  means 'client-originated message';
         (g) --> means 'get';
         object.attribute -->  maps to a remote object exposed by the server( actually a method that will process the info and return the resulting data)
         (p) --> [OPTIONAL] is an XML attribute transporting the modifier
          modifier --> [OPTIONAL] is some parameter passed that may modify the way the server formats or returns the data.


a.1.2. Client messages that request for data (SET ACTION) are issued using a <c s="object.attribute" p="value" /> where:

         (c) -->  means 'client-originated message';
         (s) --> means 'set';
         object.attribute -->  maps to a remote object exposed by the server( actually a method that will process the info and update the remote data)
         (p) --> [MANDATORY] is the XML attribute transporting the new submitted data;
          value -->  is the new submitted value.

NOTE:  SET messages to the server do not directly return data to the client HOWEVER it may trigger other processes on the server that will cause data to be dispatched to the server ( such as updating the view )

a.1.3. Client messages that target remote methods on the server (which DO NOT RELATE WITH exposed and persistent remote objects ( CALL ACTION ) are issued using a <c c="class.method" p="param1*param2" /> where:

        (c) --> the tag, means 'client-originated message'  ;
        (c) --> the attribute, means 'call' or 'command' ;
        class.method --> map to an exposed service;
        (p) --> [OPTIONAL]  is the XML attribute that transports the parameter to pass to the remote method.
        param1*param2 --> a list of parameters separated by asterisk.
         
Examples of this type of services would be changing one's password or performing a logout.


A.2 - SERVER MESSAGES


a.2.1. Server originated commands are sent using a <object-attribute d="value1*value2*value3" /> format where the tag name a mapping of the remote object that holds the returned the data , (d) is the XML attribute which presents the data being returned in the form of a asterisk-separated list of values.


A.3 - FORMATING COMPLEX DATA

a.3.1 Data of complex type( such as lists ) or data that needs to be Unicode formated are not suitable to fit the d="someValue" format.

a.3.2. -  More complex data must be sent using a sequence of <d> nodes.Example:

<global-messages>
    <d>Msg1</d>
    <d>Msg2</d>
    <d>Msg3</d>
</global-messages>


a.3.3  -  Such <d> nodes suport CDATA tags for Unicode strings. Example: 

<global-messages>
    <d><![CDATA[ Unicode text1 ]]></d>
    <d><![CDATA[ Unicode text2 ]]></d>
    <d><![CDATA[ Unicode text3 ]]></d>
</global-messages>

a.3.3  -  Such <d> nodes suport <i> subnodes to list items of a list (array). Example: 

<brisbane-couples>
    <d>
      <i>Tari</i>
      <i>James</i>
    </d>
    <d>
      <i>Robert</i>
      <i>Jill</i>
    </d>
</brisbane-couples>


a.3.4. - Both <d> nodes and their subnodes ( <i> ) should support type coercion if a t=""  attribute is present.Initially only coercion to integer numbers ( t="n" ) should be implemented.