Logo

C H A I M S: Compiling High-level Access Interfaces for Multi-site Software

Towards the Science of Component Engineering 
Logo


XML and CHAIMS

Why XML for CPAM:

- extensibility
- human-readable
- parsers in C++ and Java
- XML possible every part of CPAM protocol, not just for method parameters
- better tool for message paradigm than what we have so far....

Simple data manipulations

with XQL......, not data transformation
Advantage: So far we have assumed that the input and output parameters of megamodules belonging to the same suite match each other. If we extracted a parameter A from one megamodule, we could route it on as parameter B into another megamodule, without making any changes to it (see also keyword SYNONYM in repository). If we wanted to merge several results of megamodule 1 (either different output parameters from the same method invocation of  the same output parameter from repeated invocations of a method), we needed a special mediator megamodule that is able to read exactly this opaque type.
 
Data manipulation (better term?) versus data transformation
Data transformation takes a set of data values (simple or structured data), and changes them into new values. For instance, two numbers are added together, or given the name, age and adress of a person the horoscope of the person is calculated.
Data manipulation does not change values, it just changes to structure of data. For instance, given the three parameters name, age and adress, it might put them together into the one parameter  personaldata. Or given several flight-info records, these records might be put into one list. 

In the context of XML we could use parsers and XQL to extract data from one or several XML-documents, and then put them together into one XML document.

Which parts of CPAM?

1) One XML-document for each method parameter

Just replaces the current ASN.1 encoding by XML.

1.a) The following XML directly uses the names of data elements as
 

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE CHAIMSGentype>
<CHAIMSGentype>
   <DEC  param = "PersDat" type="complex"  name = "Personal Data">
      <DEC  type="list"  name = "Person's Name">
        <DES param="FName" type="string" name="First Name">Dorothea</DES>
        <DES param ="LName" type="string" name="Last Name">Beringer</DES>
        <DES type="string" name="Middle Initial">I</DES>
        <DES type="string" name="Other additional first name">AAAA</DES>
        <DES type="string" name="Other additional first name">BBBBBB</DES>
        <DEO name="additional info"  type="list" description="my data"> </DEO>
      </DEC>
       ........ other data like address
    </DEC>

</CHAIMSGentype>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE CHAIMSGentype>
<CHAIMSGentype>
   <PersDat   type="complex"  name = "Personal Data">
      <Name  type="complex"  name = "Person's Name">
        <FName type="string" name="First Name">Dorothea</FName>
        <LName type="string" name="Last Name">Beringer</LName>
        <IName type="string" name="Middle Initial">I</IName>
        <AFName type="string" name="Other additional first name">AAAA</AFName>
        <AFName type="string" name="Other additional first name">BBBBBB</AFName>
      </Name>
       ........ other data like address
    </PersDat>
</CHAIMSGentype>

2) One XML-document for the whole list of method parameters

Advantage: This would allow us to blur the strict separation of the data into the different parameters.

An XML that strictly inforces the separation into different parameters would look like:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE CHAIMSMethodParameters>
<CHAIMSMethodParameters>
  <CHAIMSGentype>
    <PersDat  type="complex"  name = "Personal Data">
     .......
    </PersDat>
  </CHAIMSGentype>
  <CHAIMSGentype>
    <Par2 ....>  ...... </Par2>
  </CHAIMSGentype>
  <CHAIMSGentype>
    <Par3 ....>  ...... </Par3>
  </CHAIMSGentype>
</CHAIMSMethodParameters>
I rather suggest an XML that gets rid of this strict separation:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE CHAIMSMethodParameters>
<CHAIMSMethodParameters>
    <PersDat  type="complex"  name = "Personal Data">
     .......
    </PersDat>
    <Par2 ....>  ...... </Par2>
    <Par3 ....>  ...... </Par3>
<CHAIMSMethodParameters>
In above representation, the only difference between several parameters and on paramater containing the data of all the parameters is a bracketing name-type markup. The following document contains the same data, only this time the method has only one parameter, namely Horoscopedata, instead of the three parameters PersDat, Par2, Par3 as above.
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE CHAIMSMethodParameters>
<CHAIMSMethodParameters>
    <PersDat  type="complex"  name = "Personal Data">
     .......
    </PersDat>
    <Par2 ....>  ...... </Par2>
    <Par3 ....>  ...... </Par3>
<CHAIMSMethodParameters>

One XML-document for all parameters of a CPAM primitive

(in, inout, out, return value) k

One XML-document for the whole primitive

the name of the primitive being part of the XML document
 
 
 
 
 
 
 


Logo Back to the CHAIMS homepage