|Version 21 (modified by fbatard, 5 years ago)|
Finish off with the bugs to transfer everything under XMLBeans
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. I think we still have to improve it to treat all the cases.
For example we have to test if we can do mutiple <if> tags. <if> inside <if> inside <if>
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 ParamType? of the tasklist --> can improve the textfield ... etc..
I'll guess we'll have to add some too in order to implement the new functionnalities.
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
I think there some classes we got to completly change especially the Unmarshaller.
Every single reference to priority system should also disappear.
We could change that into execution level.
In the tasklist we can perform a pre-formatting to replace all the occurence of subtasks inside a task
That will simplifies the mechanism or recursion ( tkz Jean-Gui ;) )
The current debate inside the trainees is how to replace the current priority system with a level of execution.
- First solution : build a list inside a list . The first list is the different level of execution , the second is the list of the command that we'll be executed at that level.
- Second solution : do it sequentially. Once we replaced the subtasks we just parse the resulting tasklist and execute all the <exec> tag at the same level at the same time
Changes to commit on dev
- Should we commit the observationresponse performed with XMLBeans and introduce therefore the new librairies ?
- Should we commit the various tests we've done about XMLBeans , JigSawTest? and the taslkist schema generated sources ?