week4+

 == Finish off with the bugs to transfer everything under XMLBeans ==

We finished what I've been doing under the observation response in [wiki:week3+]BR We finished to correct the bugs in the response.parser.DefaultParserBRBR

We also got to change the package name from org.w3.unicorn to org.w3c.unicorn to stay relevant.This can be done by changing the namespace in the schema. The scomp method will generate everything by itself like a good boy :). The problem is that the ucn output on the validator are w3.org ... and it doesn't match what we defined to be w3c.org... therefore -> type mismatch

 = Get started with the new tasklist =

We cared about the new schema in order to enhance it and use it in XMLBeans You can find the schema attached in this page.BRBR List of classes to change only to adapt the tasklist to XMLBeans :

• UnicornCall --> call the task depending on the priority --> to change with the different level of execution
• IndexGenerator --> Generate the indexes, with some priorities parameters, rest should remain unchanged
• RequestList --> Get the request depending on the priorities
• Observation --> Get the observer with its priority
• RDFUnmarshallerjena --> a single reference to priority index
• TasklistUnmarshallerJAXB -->All deprecated because of JAXB
• Parameter --> Use the Ui parameter of the tasklist
• ParameterFactory --> Use the TParamType of the tasklist --> can improve the textfield ... etc..

I guess we'll have to add some too in order to implement the new functionnalities. BR In order to match with XMLbeans philosophy we had to add extra child nodes in cond node in order to get the inner text. Indeed XmlBeans doesn't like nodes with attribute and inner text at same. If we would have done so , the generated classes couldn't access to the inner text of the node. Therefore we created these extra nodes.

---

 == Define the new functionnalities to implement and how ==

BR I think there are some classes we got to completely change especially the Unmarshaller. BR Every single reference to the priority system should also disappear.BR We could change that into execution level.BR In the tasklist we can perform a pre-formatting to replace all the occurences of subtasks inside a taskBR That will simplifies the mechanism or recursion ( tkz Jean-Gui ;) ) BRBR The current debate inside the trainees is how to replace the current priority system with a level of execution.BR

• First solution : We could build a n-ary tree. We would have a NODE which is a list of <exec></exec> and a list of <if></if> for each execution level. The <if></if> datatype will contain a condition to check and a reference to NODE if the cond pass and a reference to a NODE if the condition fails (to simulate the else).

 == About the condition will we have other types than mimetype and xpath? Should we do an enum ? == 

We can then evaluate the condition depending on its type and follow a different node depending on the result.BR This tranformation from XML to this data structure might be done in TasklistUnmarshaller. The execution of the algorithm might be done in the UnicornCall.BR We'll also have to change all the references to priorities and find a new system for them.BR We got to :BR

    * Completly change the Unicorn Call to implement the new functionnalities
    * Completly change the TaskListUnmarshaller
    * Completly change the Observation class
    * Find a way to replace smartly the occurences of Priorities in others classes (execution level if we can)
    * Adapt the Parameter and ParameterFactory with the new enumeration tUi

BR

• Second solution : do it sequentially. Once we replaced the subtasks we just parse the resulting tasklist and execute all the <exec></exec> tag at the same level at the same time
  • impossible to implement and poor in a term of performance
• Third solution : Pre process the XML of the tasklist and create a fake-compiler to process this XML as it looks like a programming language.
  • Might be sooo heavy to settle just to process some ... then we gave up. Might be a good idea for more complex systems

 = Features to commit on dev = 

• Should we commit the observationresponse performed with XMLBeans and introduce therefore the new librairies ? yes
• Should we commit the various tests we've done about XMLBeans , JigSawTest and the taslkist schema generated sources ? yes