Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

XML in ICE

Revision as of 08:51, 23 July 2015 by Smithrw.ornl.gov (Talk | contribs) (Created page with "This section will discuss a prototype about implementing a plugin to allow the parsing and creation of XML files in ICE. == The Reason == One of the key features of ICE is t...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This section will discuss a prototype about implementing a plugin to allow the parsing and creation of XML files in ICE.

The Reason

One of the key features of ICE is the ability to modify simulations by allowing the user to adjust command line arguments and file paths for their program. ICE needs a way to store the data in various types of files for multiple scenarios, including setting up the simulations and their respective models. Thus, the prototype to manage XML was created to ensure this in a safe, and efficient way.

What type of Parser

The parser that will be used for the program will use the JAXP library. It will load the XML files into memory for speedier parsing results by using the DOM parser, since the XML files are going to be small.

XML Schema for Model Profile

Currently, the Model Profile and Simulator Profile will be shared. Here is a sample ps.app file from the previous version of ICE 1.0

AppName=ps ComputingPlatform=derp.derp.com ExecutionString=ps cat ${MIP} ProblemTypes=Show Running Processes Show_Running_Processes_Option=All

This is a sample schema created using Eclipse XML Schema creator:

Schema Model:

 <xmlns:tns="http://www.example.org/SimulatorModel" elementFormDefault="qualified">
 
   <complexType name="Model">
 
        <sequence>
 
            <element name="AppName" type="string"></element>
 
            <element name="ComputingPlatform" type="string"></element>
 
            <element name="ExecutionString" type="string"></element>
 
            <element name="ProblemTypes" type="string"></element>
 
            <element name="Show_Running_Processes_Option" type="string"></element>
 
        </sequence>
 
    </complexType>
 
</schema>

XML Schema for Simulator Profile

-Under Construction-

Implementation

The implementation of the plugin that manages the parsing and creation of XML, known as the XMLManager, will be modeled in RSA and transformed into java. The ICE program will interface with a set of operations to call upon the XMLManager. ICE will be able to request parsing of an approved XML file, the creation of a specific type of XML file, and to be able to create an instance of the XMLManager. To contain the information of the data being transported between XML to ICE and back will be an abstract data structure called XMLFileItem. Currently, there are two types of XML files that ICE will accept: Simulator Profile and a Model Profile.

The XMLManager will be able to create instances of the objects that parse the XML file, XMLParser, and create delegated XML files, XMLCreator. The XMLParser and XMLCreator are both abstract, so there will need to be profile identifiable Parsers and creators for each profile. The XMLManager can create these instances through a factory call, titled XMLDelegationFactory, where it will return a reference of those objects. Once the XMLManager has references to the XMLParse/Creator, it will then be able to call the appropriate function to either parse an XML file given it's directory path, filename and type of profile, or be able to create an XML given the same as stated before plus the XMLFileItem structure with the required information to inject into a new XML file. The XMLFileItem will have cooresponding data to the specific profiles.

Finally, there will be preset schemas to each profile so that the parser's can confirm legal XML files to be put into the program.

Testing

Since the implementation is done in a TDD environment, the modular pieces of code will need to be thoroughly tested for various scenarios. These scenarios include, but are not limited to:

  • Bad XML Files - incorrect formatting, wrong profile identifier, etc.
  • Incorrect values in XML files
  • Trying to create XML files with bad XMLFileItems
  • XML Files too big to be read
  • Errors concerning lower level functionality, including errors with JAXP and passing null arguments

The TDD strategy is broken down recursively. Each method will be tested within each class. Then those classes will go through integration tests. Since there is functionality for reading and writing to XML files in the program, there will need to be legal and illegal XML test files to test for data integrity and correct XML usage. They will go through several stages of XML parsing and schema validations.

Back to the top