#6 Fingers Crossed For The First Eval!

Currently, the first evaluation phase is underway and ends tomorrow,  on the 28th of June. Prior to actually opening the evaluation form, I was expecting a long questionnaire. But it turned out to be a rather small one!

The last week went pretty smooth, so as to say. Thankfully, I did not encounter any new issues in the code. But I had to do one tedious job alongside coding the constraints. For the set of constraints, I am currently working with, the test files are faulty, and actually, do not contain the elements that I need to test. As a result, I need to edit all the test files to include appropriate XML elements and attributes. And this is, needless to say, a very tedious job! But I started enjoying that eventually. I reduced the job to just copy paste, by making a template and then making the minor changes so that it fails (or succeeds).

As I said in the last post, I will start discussing some of the broad types of constraints that I am implementing in my project. In this post, I'll discuss the constraints regarding CORE attributes and elements.

1)

" A <some_spatial_element> object may have the optional SBML Level 3 Core attributes metaid and sboTerm. No other attributes from the SBML Level 3 Core namespaces are permitted on a <some_spatial_element>. "

Let us take an element as an example. In XML, a Domain element would be typically written as:

<spatial:domain spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">

The prefix spatial indicates that the element/attribute belongs to the spatial namespace. If an element/attribute does not have a prefix, it is considered to belong to the core package of JSBML. The rule says that this element (Domain) can have 'optional' attributes 'metaid' and 'sboTerm' from the core. This means that these are not compulsory but can be added. Thus the following XML examples are valid:

<spatial:domain metaid="someString" spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">

<spatial:domain sboTerm="SBO:0000001" spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">

Whereas, the following XML is a wrong XML as it contains an attribute 'foo' which is not recognized by core.

<spatial:domain foo="someString" spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">

To implement this check, we simply return the helper function for unknown core attributes as:

func = new UnknownCoreAttributeValidationFunction<Domain>();


2)

" A <some_spatial_element> object may have the optional SBML Level 3 Core subobjects for notes and annotations. No other elements from the SBML Level 3 Core namespaces are permitted on a <some_spatial_element>. "

Continuing with the same example, an XML element can have multiple children elements. The domain element typically has listOfInteriorPoints as its child. But it can have the <notes/> or <annotation/> element from core as its child too. Thus some valid XMLs look like:

<spatial:domain spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">
     <notes/>
</spatial:domain>

<spatial:domain spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">
     <annotation/>
</spatial:domain>

The following example is an invalid XML because the element <foo/> does not exist in the core.

<spatial:domain spatial:domainType="domainType_1" spatial:id="domain_1" spatial:name="someString">
     <foo/>
</spatial:domain>

To implement this check, we again simply make use of a helper validation function for unknown core elements:

func = new UnknownCoreElementValidationFunction<Domain>();

In the next blog post, I will continue with the discussion on constraint implementations, and give further updates on my project.

Till next time,
Cheers! :D

#5 First Evaluation Approaches!

The first phase of coding is nearing its end, and the first evaluation is due on June 24th.

The first 4 weeks of GSoC have been immensely rewarding in terms of learning and working experience. Since the existing code was quite old, I encountered quite a few problems any time I worked on a new type of constraint. With the help of my mentor, I was able to fix pretty much all of those issues, saving one or two odd issues.

In this blog post, I'll discuss some more issues that I encountered along the way and their solutions in short.

1.

Once I started implementing checks for core attributes on spatial elements, I noticed sometimes they were not being stored in the UNKNOWN_XML. The attributes on a spatial element are read by the readAttribute() method of the respective spatial class. The problem was due to the statement like:

   boolean isAttributeRead = (super.readAttribute(attributeName, prefix, value))

                          && (SpatialConstants.shortLabel == prefix);

The problem here is the condition that prefix is the same as the shortLabel, which is nothing but the package name. Core attributes do not have any prefix and thus they are finally considered not processed as isAttributeRead becomes false.

Just removing the second condition does the fix and the core attributes are read properly.

2.

A major problem, due to which some constraints were facing issues, as I mentioned in the previous blog, was regarding the ListOf<> elements.

In classes such as Domain.java, there are ListOf<?> elements which are children on these classes in the XML. The checks for such ListOf<?> elements included checking core elements and attributes. 

The problem was that the unknown core elements or attributed were being added to the UNKNOWN_XML of a ListOf context object, but the ListOf was being duplicated during the flow of the program because of a faulty isSetListOf() method:

   public boolean isSetListOfInteriorPoints() {
      if ((listOfInteriorPoints == null) || listOfInteriorPoints.isEmpty()) {
         return false;
      }
      return true; 
   }

This method, apart from checking if the container is null, also checks if it is empty. As a result, new containers were being initialized in the code when the container was not populated.  So, the UNKNOWN_XML belonging to the previous container is lost and the checks fail. 

Again, just simply removing the condition listOfInteriorPoints.isEmpty() does the job and the tests start working properly.

In forthcoming blogs, I will start discussing the various categories (broadly) of constraint rules, and their implementation.

Till next time,
Cheers! :-D

#4 Writing My First Constraints

The last week was quite interesting as I got a hang of writing my own constraints, and things started moving ahead smoothly, for most of it!

To make my work easier, I created a template of a Constraint Class, with all the documentation and the constructs common to all constraint classes. I pretty much just need to insert the class name at 2-3 odd places to make it ready for the actual checks.

JSBML (core) has a bunch of 'helper classes' which contain some frequently used validations. Most other validations are extensions of these helper functions, and sometimes, I use them directly.

I'll describe some of these classes briefly here:

1) DuplicatedElementValidationFunction
    This class is used to check that a child XML element was not present more than once.

2) InvalidAttributeValidationFunction
    This class is used to check if any invalid XML attributes were found in an element. The argument for the constructor of this class is the attribute name.

3) UnknownPackageAttributeValidationFunction
    This class is used to check if any unknown XML attributes from a specified package/namespace were found. The constructor for this class takes the package name as an argument. For spatial, we pass SpatialConstants.shortLabel (SpatialConstants is the class containing various constant strings related to the spatial package. The shortLabel constant contains the namespace string)

4) UnknownPackageElementValidationFunction
    This class is used to check if any unknown XML elements from a specified package/namespace were found. The argument for the constructor is the same as the previous class.

5) UnknownCoreAttributeValidationFunction
    This class used to check if any unknown XML attributes from SBML core were found.

6) UnknownCoreElementValidationFunction
    This class used to check if any unknown XML elements from SBML core were found.

I had studied the various packages for which constraints had already been implemented, and that helped me to figure out in advance on how to use these classes.

Now I'll come to the modifications that were required in the existing code of spatial.

The first major change had to be made to the SpatialParser.java . In the method processStartElement, every time we got a match for the contextObject as an instanceof some class, I needed to add the element being read to a list which would be utilised in later validations by classes such the DuplicatedElementValidationFunction. The classes would then be required only to get the data from this list. This had to be done by using the AbstractReaderWriter class and call its method storeElementsOrder(). Also, if we did not get a match for any element after the previous check, I had to invoke the processUnknownElement() method of the AbstractReaderWriter to handle the unknown element.

The next change was in StringTools.java from JSBML Core. I had to add a method to parse a string as double and throw an exception if it was not able to. The existing method did not throw an exception, and only registered a warning in the logger.

There is one change which I have to make to the source class (for which I am writing the constraint) of every constraint class. In the readAttribute() method of the class, I need to add AbstractReaderWriter.processInvalidAttribute() wherever we have a try/catch construct to assign a value to an attribute. This must be done to handle invalid attributes as we encounter them.

This was pretty much what I explored and worked on in the past week. I have implemented constraints for around 13 classes successfully by now!
I am experiencing some issues in 1 or 2 odd classes, which I shall discuss once I solve them!

Till next time,
Cheers! :-D

3# First Week Of Coding

The coding period for GSoC'19 officially began on May 27th (Monday).

The first week was pretty much spent in properly setting up the tests for the constraint classes. I tried setting up the project with the help of my mentors during a hangout meeting multiple times.

At first, the OfflineValidatorTests.java was not able to locate classes of the spatial package. But things only got worse later when the class itself refused to run! 3 failed attempts later, we decided that for the time being, I could create a bigjar of the entire jsbml project and run the tests via the command line as:

~$ ant bigjar
~$ java -classpath dist/jsbml-1.5-SNAPSHOT/jsbml-1.5-SNAPSHOT-with-dependencies.jar org.sbml.jsbml.test.OfflineValidatorTests /home/bhavye/GSOC/syntactic-cases-2017-11-20 spatial-20201 xml

I tried to set up the project myself afterwards and got it running finally. In the following text, I will describe the process I followed to get the tests up and running.

1. Create a new workspace in eclipse.
2. From the 'File' drop-down menu, select 'Open Projects from File System'.
3. Locate the jsbml (cloned) directory and select.
4. Select 'Finish' with default options selected. 
5. In the package explorer, enter core -> test -> org.sbml.jsbml.test
6. Right click on OfflineValidatorTests.java -> Run As -> Java Application
7. Now again right click on  OfflineValidatorTests.java, go in 'Run As' and select 'Run Configurations'.
8. Enter the 'Dependencies' tab, and select 'Classpath Entries'.
9. Select 'Add Projects...' and check the tick box of spatial.
10. Enter the 'Source' tab and select 'Add...'.
11. Select 'Java Project' and check spatial.

The arguments for the configuration would be of the format:

<test files directory> <error codes (separated by colon if range)> xml

eg:

/home/bhavye/GSOC/spatial-test-files spatial-21305 xml

/home/bhavye/GSOC/spatial-test-files spatial-21301:spatial-21305 xml

The alternate, rather the more neat way of setting up the project would be to select 'Create a New Java Project' at the beginning and then proceed to clear unwanted files from the build path. But that created unforeseen errors. It generates a bin folder to keep all the class files, and so, having the jsbml/bin folder as the default output folder for every project should have worked in the first place.

So finally having my project running, I started creating the actual constraint classes and tested them along the way. I will discuss the modifications in the existing code and the new problems in the forthcoming blogs!