Tuesday, July 23, 2019

#9 Second Evaluation Approaches

Greetings everyone!

Since a lot has not transpired in the last two weeks, I decided to write a combined blog for both. Last week, I completed implementing the rules provided in the Spatial package specification. In a sheer coincidence, I crossed 100 commits and 10k lines of code in the process too!

While implementing constraints for MixedGeometry, I had to make some changes in the SpatialParser. The parser had no case to handle elements with ContextObject as MixedGeometry. So I added the block to read listOfOrdinalMappings and listOfGeometryDefinitions. Also, the parser did not have the code to read the OrdinalMapping element, so that was added too.

The implementation of the rules for this class was pretty straightforward, but I encountered a small problem while testing some of the rules. Earlier, the parser recognised geometry definitions as a child of listOfGeometryDefinitions belonging to the main Geometry element. But MixedGeometry also has a listOfGeometryDefinitions. The geometry definitions in this list were being wrongly stored as children of the Geometry element. So I created a new addGeomteryDefinition() method which adds the GeometryDefinition to the correct parent by checking the parent ContextObject.

These corrections and additions in the SpatialParser also fix many of the problems that were encountered while reading and rewriting the test files using stax. Implementing rules for OrdinalMapping and SampledFiled were straight forward too, although I had to edit some test files along the way.

Now I enter the last phase of GSoC, where I'll try to figure out some more rules from the text of the specification, and once approved by my mentors, I shall implement them. I shall resume discussing the different constraint rules in my next blog. 

Till next time,
Cheers!

Friday, July 12, 2019

#8 Last Week Of My Summer Break

Greetings Everyone!

In the previous week, I had been working on constraint classes for ParametricObject class and the SpatialPoints class.
I did not encounter any major problems while implementing the two classes but did have to ask for some clarifications
from my mentors along the way.

The ParametricObject element has an attribute called pointIndex, which is written as values outside the XML tags as:

<spatial:parametricObject spatial:compression="uncompressed" spatial:dataType="double" spatial:domainType="domainType_1" spatial:id="parametricObject_1" spatial:name="someString" spatial:pointIndexLength="0" spatial:polygonType="triangle">
    0 2 5; 0 6 2; 0 5 6; 2 6 5
</spatial:parametricObject>

I did not know how these values are being read. It turned out that there is a method processCharactersOf() in SpatialParser which reads these
values and calls the append() method of the ParametricObject class. The method appends the values to a string variable pointIndex one by one.

After this, the check on the values was fairly simple. I used StringTokenizer with an alternate constructor, passing a string of delimiters
" ;" as an argument. This argument helps the StringTokenizer to separate the string "0 2 5; 0 6 2; 0 5 6; 2 6 5" whenever it encounters a
space or a semicolon, thus returning the individual values.

For the SpatialPoints class, I still need to verify with a mentor of mine if the 'id' and 'name' attributes are a part of the new specification.
After that, necessary changes will be made either to the test files, or the existing class to incorporate the final decision.

Today I shall discuss checks on invalid and unknown attributes on an element.

1)
The value of the attribute <attribute_name> of a <spatial_element> object must be an array of values of type <datatype>.
OR
The value of the attribute <attribute_name> of a <spatial_element> object must conform to the syntax of SBML data type 
<datakind_class> and may only take on the allowed values of <datakind_class> defined in SBML; that is, the value must 
be one of the following: “value_1” or “value_2”.

For such rules, the first step is to modify the source class to handle invalid attributes whenever they are encountered.
In the readAttribute() method of the class, look for a branch condition on attributeName.equals() for the concerned attribute.
There must be an enclosed try-catch block inside the branched block of code. The try block sets the value of the attribute,
and the setting method throws an exception if the value is not syntactically correct. This is caught by the catch block, and
that is where we need to add the following line of code:

AbstractReaderWriter.processInvalidAttribute(attributeName, null, value, prefix, this);

This call handles the invalid attribute and adds it to the INVALID_XML object of the class.
Now the constraint is impemented by a single line as:

func = new InvalidAttributeValidationFunction<spatial_element>(SpatialConstants.<attribute_name>);

2)
A <spatial_element> object must have the required attributes <attribute_1> and <attribute_2>, and may have the optional 
attributes <attribute_3>, <attribute_4> and <attribute_5>. No other attributes from the SBML Level 3 Spatial Processes 
namespaces are permitted on a SpatialPoints object.

The helper class for such a rule is UnknownPackageAttributeValidationFunction. We need to override the check() method
to incorporate test on the must-required attributes. We call the pre-implemented check() method by a super call after
checking must-required attributes.

func = new UnknownPackageAttributeValidationFunction<element_name>(SpatialConstants.shortLabel) {
     @Override
     public boolean check(ValidationContext ctx, SpatialElement obj){
if(!obj.isSetAttribute1){
    return false;
}
if(!obj.isSetAttribute2){
    return false;
}
return super.check(ctx, obj);
     }
};

Saturday, July 6, 2019

#7 Coding Continues

Greetings people!

The results of the first evaluation were released last week, and I'm glad that I have passed to the next phase of the program, with a positive response from my mentors.

I was not able to do a lot of work in the past week, but I managed to implement constraints for 2 more classes, namely, CSGPrimitive and CSGSetOperator. I did face a bit of problem with CSGSetOperator initially as the XML was not being read properly. I figured it out as a problem in the SpatialParser.

The parent of the listOfCsgNodes element was being read as CSGObject but it should have been SCGSetOperator. CSGObject is usually the parent of CSGSetOperator. Thus it was accessing the parent of the parent and hence the problem. A simple deletion of the getParent() call (where it appears for the second time) did the fix.

As of now, only 6 classes remain to be implemented. I hope to complete the preliminary work by the end of the next week. After that, I'll start working on adding constraints by hand.