Abstract:
A software data interface technique allows a program to retrieve data from another program, whether or not data formats employed by the two programs are mutually compatible. An application-independent data format, F exchange , is a priori agreed upon and readable by creators of the two programs. In the course of storing data during execution of a first program, that data file is augmented to include instructions that convert the format of the data into the application-independent intermediate data format, F exchange . During execution of the second program, whenever access of data stored in the first program is required, the second program retrieves from the first data file instructions for converting the format of the data to the application-independent intermediate data format, F exchange . The second program then executes the conversion instructions so as to retrieve the data from the first program.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention relates in general to communication systems and subsystems thereof, and is particularly directed to a software data interface technique that allows a first communication application program to retrieve data from a second communication application program, irrespective of whether or not the data formats employed by the two communication application programs are mutually compatible.  
       BACKGROUND OF THE INVENTION  
       [0002]     The communications industry has available to it a number of software application programs that allow an operator to model a radio communication network. As a non-limiting example, the Radio Programming Application (RPA) software application created by Harris Corp.—the assignee of the present application—captures data supplied by an operator, the data typically including details such as, but not limited to, exact radio names, radio types, RF network connectivity, IP network connectivity, telephony network connectivity and the like. Many of these details are also needed by other radio communication software applications, such as but not limited to Harris Wireless Message Terminal (WMT), Harris Tactical Chat® IP and Harris RF-6010 Network Management Application, each of which is operated by the assignee of the present application. One brute force and very time consuming mechanism to configure each application with the parameters necessary for its operation would be to have a user enter all of the necessary data into each application.  
       SUMMARY OF THE INVENTION  
       [0003]     In accordance with the present invention, there is provided a communication software data interfacing technique that significantly relieves the above user burden, by means of a software data interface or intermediate data conversion mechanism that makes data available in an application-independent data format previously agreed to by users of multiple applications. To this end, the supplier of shared data provides an agreed to set of known entry points for accessing the shareable data in the same file as the data itself. In accordance with preferred, but non-limiting, embodiment, the well known entry points employ XML (extensible markup language) nodes with an agreed upon labeling convention. These nodes may be identified as CDQ (which is an abbreviation of the phrase “common data query,” which is a technical abbreviation for this method). Each node has a plurality of attributes, including a version (“version”), a type (“type”) and a name (“name”). Thus, an example of a node would be the statement: &lt;CDQ name=“Station General Query” type=“xsl” version=“1.0”&gt;. The set of named queries that is included with any given data set is agreed to by both the supplier and the consumer of the shared data. The consumer agrees to access the data in the file exclusively through this set of ‘intermediate’ queries, rather than directly retrieving the data.  
         [0004]     Given this set of queries for representing access points for a respective set of data, a consumer may access the data by opening the data file and then locating the query of interest, using the “name”, “type” and “version” identifiers previously agreed upon during a preliminary contract negotiation session among all users of the technique. In addition, the consumer decompresses contents of the node using an agreed upon compression/decompression standard. For queries of type “XSL”, the result of the decompression step is an extensible stylesheet language template (XSLT) stylesheet through which the entire data file is to be processed (using the consumer&#39;s choice of XSLT processor). This stylesheet, together with any consumer supplied arguments, is defined as a “Query Input.” The result of XSLT processing of the Query Input is termed a “Query Output.” For XML type queries, the result of the decompression step is the Query Output directly. The consumer then extracts the data from the Query Output and closes the data file.  
         [0005]     More particularly, considering an overview of the methodology of the present invention, as a first step, an arbitrary first version of a first application program stores shared data that is needed by a second application program. Within the first version of the first application program, data is stored in a first format. For an updated or more recent version of the first of application program, data is stored in a corresponding updated format. For successful data exchange between programs, the second application program must be data exchange-compatible with the first application program. Namely, it is necessary for the second application program to be able to read the data files generated by the first application program, irrespective of the version of the first application program. This means that the second application program must be able to retrieve data from files stored in any format, which could be generated by some version of the first application program. For this purpose an application-independent ‘intermediate’ data format, termed F exchange  is agreed upon by the creators of all application programs that will have access to the shared data. To this end, the second application program is created to ‘read’ data in this agreed upon intermediate data format F exchange . A key feature of the present invention is the fact that whenever a data file is created by the first application program, associated instructions necessary to convert from any arbitrary format to the F exchange  format are inserted into the data file generated by the particular version of the first application program. These conversion instructions are accessible by the second application program upon accessing the data file of interest. Then, whenever the second application program needs to read data that has been generated by the first application program, the second application program retrieves intermediate F i -to-F exchange  conversion instructions that were created and inserted within that data file contained within the first application program and proceeds to execute the conversion steps described by those instructions, thereby successfully accessing the data from the first application program. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0006]      FIG. 1  is a flow chart showing a general overview of the shared data interface employed by the present invention for the case of two arbitrary application programs A 1  and A 2 , which do not necessarily have data exchange compatibility with one another;  
         [0007]      FIG. 2  depicts a routine through which a program A 2  is able to retrieve data from files stored in any of the formats (F 1 , F 2 , . . . , F N ) which could be generated by some version of program A 1 , in particular showing details necessary for the steps  101  and  102  of the overview flow diagram of  FIG. 1  to be successfully completed; and  
         [0008]      FIGS. 3A-3D  form a process flow diagram of the steps of the present invention that provides a non-limiting example of various technical parameters associated with reading data employed in a radio communication network in implementing the steps of the flow diagram of  FIG. 2 . 
     
    
     DETAILED DESCRIPTION  
       [0009]     Before detailing the application independent shared data retrieval methodology for fully synchronously interfacing data between disparate (radio communication) application programs in accordance with the present invention, it should be observed that the invention resides primarily in a prescribed novel software program that is readily executed via conventional digital processing circuits and components. Consequently, the configurations of such circuits and components and the manner in which they may interface with radio equipment making use of the invention have been shown in the drawings by readily understandable flow charts and associated block diagrams, which show only those specific aspects that are pertinent to the present invention, so as not to obscure the disclosure with details which will be readily apparent to those skilled in the art having the benefit of the description herein. Thus, the flowcharts and diagrammatic illustrations are primarily intended to show the major components of the invention in convenient functional groupings, whereby the present invention may be more readily understood.  
         [0010]     Attention is initially directed to  FIG. 1 , which is a flow chart showing a general overview of the shared data interface employed by the present invention for the case of two arbitrary application programs A 1  and A 2 , which do not necessarily have data exchange compatibility with one another. It should be understood that the invention is not limited to use with only two or any other number of application programs. The number two has been selected as a non-limiting example, to facilitate an understanding of the principles and operation of the invention without unduly burdening the textual description. It will be readily understood that the invention can be readily expanded to a larger number of users of the shared data by implementing the routine described herein among respective pairs of users, so long as all users are included.  
         [0011]     Initially, as a first step  101 , an arbitrary first version V 1  of the first application program A 1  stores, in various files, shared data that is needed by one or more other applications, here by the second application program A 2 . Within version V 1  of application program A 1 , data is stored in a first format F 1 . For an updated version V 2  of program A 1  data is stored in an associated updated format F 2 . As pointed out above, the second application program A 2  is required to be data exchange-compatible with application program A 1 ; namely, as shown at step  102 , it is necessary for program A 2  to be able to read the data files generated by program A 1 , regardless of the version V i  of program A 1 . This means that in order for step  102  to be successfully executed, program A 2  must be able to retrieve data from files stored in any of the formats (F 1 , F 2 , . . . , F N ) which could be generated by some version of program A 1 . In order for the steps  101  and  102  of the overview flow diagram of  FIG. 1  to be successfully completed, the routine shown in  FIG. 2  is executed.  
         [0012]     At a first step  201 , an application-independent ‘intermediate’ data format, F exchange  is agreed upon by the creators of all application programs (programs A 1  and A 2  in the present example). In step  202  application program A 2  is created to ‘read’ data in this agreed upon intermediate data format F exchange . Next, in step  203 , whenever a data file is created by application program A 1 , associated instructions necessary to convert from any arbitrary format F i  to format F exchange  are inserted into the data file generated by version V i  of application program A 1 . As represented by step  204 , these conversion instructions are accessible by application program A 2  upon accessing the data file of interest. Then, whenever, as shown at step  205 , application program A 2  needs to read data that has been generated by application program A 1 , program A 2  retrieves the intermediate F i -to-F exchange  conversion instructions that were created and inserted within that data file, and proceeds to execute the conversion steps described by those instructions, thereby successfully accessing the data.  
         [0013]     A non-limiting example showing the manner in various technical parameters associated with reading data employed in a radio communication network in implementing the steps of the flow diagram of  FIG. 2  will now be described with reference to the flow diagram of  FIGS. 3A-3D . At first step  301  (which corresponds to step  201  of the flow diagram of  FIG. 2 ), a public interface used to access data stored in files generated by the first application program A 1  is defined, published and distributed to the makers of application program A 2 . As a non-limiting example, in step  301  a VHF UHF Radio Programming Application (RPA) public interface provided by the assignee of the present application is generated to produce a set of data queries. For purposes of reducing the complexity of the present description only two of these queries are shown as Query #1 and Query #2 within intermediate format block  311 . The format is an intermediate XML (extensible markup language) format conformed with by the public interface queries can be defined using any appropriate means, including (but not limited to) XML schema, DTD or example XML tree fragments.  
         [0014]     Next, at step  302 , application program A 2  is modified, in accordance with steps  202  and  205  described above with reference to  FIG. 2  on the one hand, and in conformance with the public interface of step  301 , to access data from the files generated by application program A 1 , described above. Specifically, in step  303 , the target data sought by application program A 2  is readily obtainable by executing one or more of the queries in the public interface supported by application program A 1 . Then, in step  304 , the data from these multiple queries is combined to provide application program A 2  with the full data set it needs. In particular, as shown at associated block  314 , a Wireless Messaging Terminal (WMT) routine will use both the “Station General Query” (Query #1) and the “Network General Query” (Query #2) of query block  311  associated with the execution of step  301 , described above. As a result of this data file access, application program A 2  is now capable of importing data from application program A 1 , as shown at step  305 .  
         [0015]     At step  306 , an arbitrary user (user 1 ) of application program A 1  executes that program. In practical terms this is shown at associated block  316 , wherein a military communications officer launches an instantiation of the VHF UHF RPA on his personal computer (PC), as by clicking upon an associated icon  326 . Next, at step  307 , user 1  enters data into the application program A 1 , that he is running on his PC. As diagrammatically illustrated in the example of block  317 , the communications officer (user 1 ) enters data into the RPA about a planned radio network the components and operational parameters of which are shown as being surrounded by broken lines  327 .  
         [0016]     Next, at step  308 , user 1  instructs his currently active application program A 1  to save data to a file “DataFile 1 ”. This operation is represented in block  318  by the communications officer clicking on the “Save File” icon  328  on his PC&#39;s graphical user interface (GUI) toolbar, and enters the filename to which to save the data, which is denoted here as “Plan1.vpd.” Next, in step  309 , application program A 1  stores user data in format F 1  which, in the present example, is XML-based, as described above. As shown by block  319 , the RPA generates a filed containing XML. Then, at step  310 , pursuant to the invention, for each entry-point in the public interface, application program A 1  appends conversion instructions to the end of the user data (within the file). In addition, within step  310 , these instructions are captured in the form of extensible style sheet language template (XSLT) stylesheets, and are contained by uniquely identified XML nodes within the XML document. As described briefly above, in accordance with the present invention, each stylesheet is specifically crafted so as to transform the data from the schema used by the file containing the stylesheet itself into the intermediate schema defined and published at step  301 . It will be readily appreciated that the stylesheets from two different versions of the same application will differ to the degree that the schema used by each version V i  of the application to capture the data is different. Block  320  shows the manner in which XML nodes may be created after the user has written to the file.  
         [0017]     At step  331 , user 1  distributes the file to user 2 . In practical terms, as shown at block  341 , the file is sent via email from a first communications officer at one location to a second communications officer at another location. Next, in step  332 , user 2  proceeds to execute application program A 2 . This is pragmatically represented by block  342 , which diagrammatically illustrates the second communications officer (user 2 ) launching an (RF-6010) Network Management Application (NMA) on his PC by clicking on an associated ICON  352 .  
         [0018]     Following the launching of the second application program (Network Management Application in the present example), in step  333 , user 2  instructs the application to load data from the file that has been obtained from user 1 . This action is diagrammatically illustrated in block  343 , by the second communications officer clicking on the load file icon  353  on the toolbar, and selecting the file of interest “Plan1.VPD.” In response to this action, the routine transitions to step  334 , wherein application program A 2  searches the file, looking for the entry-points of interest, as identified by XML nodes with expected attributes within the XML document. This action is diagrammatically illustrated in block  344 . which depicts the NMA locating the XML node in the document which contains the Network General Query using the designated XPATH query shown at  354 . For each entry point found, the second application program A 2  performs a number of operations  361 - 365 , for which there is an associated result block  371 , as follows.  
         [0019]     As shown at step  361 , the second application program A 2  retrieves the XSLT stylesheet contained as a child node of the entry-point XML node. At step  362 , application program A 2  provides the entire file as a ‘source’ document to an XSLT engine. At step  363 , the application program A 2  provides the XSLT stylesheet retrieved as the stylesheet to an XSLT transformation engine. At step  364 , application program A 2  retrieves the output of executing the stylesheet on the data file of interest. At step  365 , the second application program A 2  proceeds to parse the data in this output and populates internal A 2  databases.  
         [0020]     Once steps  361 - 365  have been completed, then in step  366 , the second application program A 2  will display the results based upon the data it has imported from the accessed file. This operation is diagrammatically illustrated at block  376 , wherein the network management application updates the GUI to show the imported station and network list.  
         [0021]     As will be appreciated from the foregoing description, the present invention is operative to relieve a user from having to reenter data for each of a plurality of different application programs that may share data, by means of a software data interface or intermediate data conversion mechanism that stores data in an application-independent data format previously agreed to by users of multiple applications. The supplier of the shared data provides an agreed to set known entry points for accessing the shareable data in the same file as the data itself. In accordance with preferred, but non-limiting, embodiment, the well known entry points may employ XML nodes with an agreed upon labeling convention. These nodes may be identified as “common data query” and each node has a plurality of attributes, including a “version”, a “type” and a “name”. The set of named queries that is included with any given data set is agreed to by both the supplier and the consumer of the shared data. The consumer agrees to access the data in the file exclusively through this set of ‘intermediate’ queries, rather than directly retrieving the data.  
         [0022]     For this purpose an application-independent ‘intermediate’ data format, termed F exchange  is agreed upon by the creators of all application programs that will have access to the shared data. To this end, a second application program is created to ‘read’ data in this agreed upon intermediate data format F exchange . A key feature of the present invention is the fact that whenever a data file is created by a first application program associated instructions necessary to convert from any arbitrary format to the F exchange  format are inserted into the data file generated by the particular version of the first application program. These conversion instructions are accessible by the second application program upon accessing the data file of interest. Then, whenever the second application program needs to read data that has been generated by the first application program, the second application program retrieves intermediate F i -to-F exchange  conversion instructions that were created and inserted within that data file contained within the first application program, and proceeds to execute the conversion steps described by those instructions, thereby successfully accessing the data from the first application program.  
         [0023]     While we have shown and described an embodiment in accordance with the present invention, it is to be understood that the same is not limited thereto but is susceptible to numerous changes and modifications as known to a person skilled in the art. We therefore do not wish to be limited to the details shown and described herein, but intend to cover all such changes and modifications as are obvious to one of ordinary skill in the art.