System Build Up Algorithm

In this section, the approaches for generating the authoring script from user’s configuration (Part A of Figure 5.4) and generating the corresponding paper-review system by the authoring script (Part B of Figure 5.4) were presented.

Figure 5.4: The detailed architecture of requirement acquisition and system generating model: The algorithm of authoring script generating will be used in Part A, and the system generating algorithm will be used in Part B.

33 5.2.1 Authoring Script Generating Algorithm

ALGORITHM 1□Authoring Script Generating Algorithm

Input: User’s configuration about the output paper-review system collect by our authoring tool

Output: The XML-based authoring script (Figure 5.5)

Step 1: Define the <paperReviewSystem> node, set name/abbreviation of the conference/journal and the purpose of this authoring script. This information was defined in Phase 2.

Step 2: Set the system profile, which consisted of basis information, system important dates, static pages, and subtopics information. This information was defined in Phase 2, too.

Step 3: Save the Role frames information and read the Role frame definition in Phase 3. For each role definition, write slot values to each slot.

Step 4: Maintain the paper category structure. The structure information was defined in Phase 4.2. It was a tree-liked structure. It created a <category>

node for each superior category. If there were some sub-categories in someone superior category, it created another <category> and insert into the superior category node recursively.

Step 5: Save the paper state information, which are defined in Phase 4.3 Step 6: Save the important dates information based on papers. There were two

types of important dates: relatively and absolutely, which were defined in Phase 4.4. For each relatively paper’s important date, set the trigger state of some paper and the day-shift information.

For each absolutely papers’ important date, it just saved the date information about this important date.

Step 7: Collect the data form information which may be used in the output

paper-review system. They are consists of register form (defined in Phase 3), paper frame (defined in Phase 4.1), proof reader form (defined in Phase 5.4), and journal frame (defined in Phase 5.5, if the purpose of the output system is conference, this frame will be skipped). The slot

information of different resource frames were stored into <attribute> node, which consisted of the slot type, the verification rules about this slot, and the information would be shown below this attribute when user

registering.

Step 8: Save the process configuration, it was divided into 5 different action setting: submit, dispatch, review, proof reader, and publish (defined in Phase 5.1~5.5).

Step 8.1: Set the slot names for those need submit first when users using a

34

2-stage submit mechanism and assigning the max # of attach files into

<submitSetting> node.

Step 8.2: Assign the min/max # of reviewer could be dispatch within a paper into <dispatchSetting> node.

Step 8.3: Set the criteria information into <reviewSetting> node.

Step 8.4: Set whether the editor need re-upload a final version of each paper or not into <prSetting> node.

Step 8.5: When user allowed paper public apart from journal/conference, she/he saved the pre/post state of the paper into <prePublic> node. If the purpose of the output system was conference, it saved the time slot information about the conference. Otherwise, it saved the indexing information about the journal.

Step 9: Save the state transition rules defined in Phase 5.1 ~ 5.5, each <rule>

node consisted of <precondition> and <postcondition> node. Precondition might have 1 or more pre-state limitation, role limitation, or sub-topic in conference/journal limitation. Post condition might assign a post-state of paper

Step 10: Save the mailing rules into <mailingDefinition> node. There were 3 types of mailing rules (defined in Phase 6).

Step 10.1: For paper state transition mail, save the target state and day-shift information into the <precondition> node.

Step 10.2: For important date mail, save the important date type, day-shift information, and the state limit into the <precondition> node.

Step 10.3: For other action mail, save the action type, and role limit involved in the action, and the state limit of paper into the <precondition>

node.

No matter the mailing type was, save the mail receiver information into

<sendTo> node. Finally, it saved the mail title/content in this mailing rule.

Step 11: output the XML.

35 Figure 5.5: The XML-based authoring script

5.2.2 Another Algorithms in the Output Paper-review system

After generating the authoring script, this thesis generated the corresponding paper-review system from the authoring script. Because the operation of the output paper-review system involved in the system implementation which was illustrated in chapter 6 in details. We just described the meta-algorithm of generating the output paper-review system at this chapter and focus on the rule inference on the paper state transition and mailing.

META-ALGORITHM □Paper-review system Generating Algorithm

Input: The authoring script of the paper-review process generated in algorithm 1 Output: The web-based paper-review system followed the user-defined

paper-review process.

Step 1: Load all the static pages definition in authoring script and rendering the hyperlink.

Step 2: Generate the dynamic pages such as index page, conference/journal papers in public.

Step 3: Maintain the register/login/logout process based on the setting of role frames and user frame.

Step 4: Maintain the access control into the actions in the paper-review process based on the setting of Role frames and User frame.

Step 5: For each actions in paper-review process, load the corresponding configuration. It would be briefly stated as below:

Step5.1: For the paper submission: load the structure of paper frame, the

36

definition of subtopic and structure of paper category. And the other setting in the <submissionSetting> node in authoring script

Step5.2: For the paper dispatch: load the setting in the <dispatchSetting>

node in authoring script

Step5.3: For the paper reviewing: load the criteria definition and the other setting in the <reviewSetting> node in authoring script.

Step5.4: For the paper proof reading: load the proof reading data form structure and the other setting in the <prSetting> node in authoring script.

Step5.5: For the paper publishing: for a journal system, it generated the journal publishing interface based on the journal frame structure; for a conference system, it generated the paper publish interface if the agenda of the conference needed published paper. Another setting about this action can be achieved in <publishSetting> node in authoring script.

Step 6: After performing different actions in the paper-review process, infer the paper state transition rules and mailing rules. This inference algorithm will be illustrated in Algorithm 2 and Algorithm 3.A in detail.

Step 7: Execute the Mailing Sending Algorithm which is illustrated in Algorithm 3.B periodically.

Because the mechanisms of rules inference make our paper-review system reconfigurable, we will especially illustrate the algorithm of paper state inference as follows.

ALGORITHM 2□Paper State Inference Algorithm

Input: a) Paper state transition rules defined in authoring scripts b) Paper frame and other facts (ex: current action).

Output: The next state of current paper frame Step 1: Set Candidate_State as an empty array

Step 2: Load all paper state transition rules into inference engine.

Step 3: For each paper state transition rule, check if the precondition of the rule matches with current paper.

Step 4: If there was any rule that its precondition satisfied, push the <poststate>

information into Canditdate_State

Step 5: If the size of Candidate_State is 0, output “After (action name) (###)”

Where (action name) was current action name, (###) was a unique serial number.

Step 6: If the size of Candidate_State was equal or greater than 1, output Candidate_State[0] + “(###)”. Where (###) was a unique serial number.

37

In algorithm 2, the size of Candidate_State should be 1 normally if the setting of paper state transition rules was correct. However, the paper state transition rules were defined by users and they might make mistake in defining these rules. The size of Candidate_State might not equal to zero. This thesis discussed this condition in Chapter 5.3. On the other hand, this thesis proposed the mechanism of mailing management.

ALGORITHM 3.A □Mailing Generating Algorithm Input: Mailing rules defined in authoring scripts Output: The sending mail jobs saved into database

Step 1: If the output system is loaded in first time, add mailing jobs if there was any mailing rule which the precondition was for the system.

Step 2: When some paper states have been changed, check if the pre-state in precondition of state transition mailing rules was current state of the paper. If yes, add a mailing job, set the sending time as current date plus the shifted days, set the state limit into database.

Step 3: When accessed some action frames and perform the action, checking if the action name in other action mailing rule was equal to current action name and current user/the role of the target of current action was match the role limit or not. If yes, it added a mailing job, set the sending time as current time, set the state limit into database.

Obviously, after the execution of algorithm 3.A, the mails were not sent out immediately. Instead, they were stored into database. That was because some mails would be check whether they still had to be sent or not at the time to be sent. Thus, this thesis executed an algorithm for mail sending periodically.

ALGORITHM 3.B □Mailing Sending Algorithm Input: The generated mail stored in database Output: The mail sent into the receiver

Step 1: Select the generated mails stored in database where the sending time was between (current time – t) and current time, where t was the time interval of invoking this algorithm.

Step 2: For each mail data, if the data consisted a paper state limitation, system checked the current state of corresponding paper, if not under the limit anymore, just skip this data.

Step 3: Based on the sendTo information of the data, assign the receivers’ e-mail of each mail.

Step 4: Before the mail being sent into the receiver, system found all the dynamic fields in mail’s title or content. If there was any dynamic field, extract the

38

dynamic field type and replace it with corresponding frame slot value.

By Algorithm 3.B, the mails in the paper-review system would be sent at a given time. In step 4, why did not the system replace all the dynamic fields in mails until the mails were about to be sent? The reason was that those dynamic fields could not be accessed necessarily. For example: The mails based on the system important dates would be imported to the database when the system loading this system first time. However, the corresponding dynamic fields such as reviewers’ name cannot be accessed because there was no user as a reviewer role yet in the system.