1 / 37

DESK ver 3.0

DESK ver 3.0. José A. Macias and Pablo Castells. Once upon a “short” time ago. DESK. Differences Model. Context Model. XML. XML. Finding out Differences. Finding out Context. Changes Management. HTML. HTML modif. Domain Model. Presentation Model. User Model. HTML. PEGASUS.

sharne
Download Presentation

DESK ver 3.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DESK ver 3.0 José A. Macias and Pablo Castells

  2. Once upon a “short” time ago... DESK Differences Model Context Model XML XML Finding out Differences Finding out Context Changes Management HTML HTML modif Domain Model Presentation Model User Model HTML PEGASUS Runtime System Authorized User

  3. DESK Client-Server Architecture Inference Engine DESK Back-End DESK Navigational WEB Pages XML User Monitoring Model WYSIWYG Authoring Tool DESK Front-End

  4. DESK Front-End • Client-Side Authoring Tool. Allows the Author to navigate and edit presentation coming from PEGASUS • WYSIWYG (or maybe a half WYSIWYG) Authoring Tool. It also includes: • A module for building conditions under User/Platform model. • A module for building iterative tasks under user conditions/data models. • Monitors and tracks the user during interaction. This way DESK Front-End creates a Monitoring Model from user actions.

  5. XML DESK Front-End Tracking and analysing User Actions ... User Action 1 User Action 2 User Action N User Action 3 Applying Low Level Heuristics Finding out Syntactic Context HL And Constructor Primitive N Constructor Primitive 1 Constructor Primitive 2 Encapsulating into Constructor Primitives ... Monitoring Model Containing Syntactic Context Monitoring Model

  6. User Actions • WYSISYG Actions • Paste, Copy, Cut • Deletion, Insertion • Create table. • Create enumeration • Applying and Disabling Styles • Font Type, Font Size, Bold, Underlying, Italic, Headers: <H1>...<H6> • No WYSISYG Actions • Create model conditions under hypermedia elements • Create model iterations under hypermedia elements

  7. Low Level Heuristics (HL)(Finding out Context) • 1st Order Heuristics address the problem of finding out client-side context for any User Action to be later identified by DESK Server-Side. Low Level Heuristics Identifying Special Structures Client-Side Context Location Module Finding out Suitable Constructor Primitives

  8. Low Level Heuristics (HL) • Finding Syntactic Context for changes on HTML • Client-Side Context Location Module ¿Witch is the nearest context for the “New Insertion”? HTML HTML HTML New Insertion New Insertion New Insertion <Insert_Single_HTML> New Insertion <In_Context location=“after”> Paragraph </In_Context> ... <Insert_Single_HTML> New Insertion <In_Context location=“before”> Paragraph </In_Context>... <Insert_Single_HTML> New Insertion <In_Context starts=15 ends=40> Paragraph </In_Context>...

  9. Low Level Heuristics (HL) • Identifying Special Structures HTML HTML Creating a table: <Create_Table id=T1 ...> <In_Context>... Inserting HTML into a Table: <Insert_Single_HTML> Text <In_Context table_id=“T1” col_n=1 row_n=1> Paragraph </In_Context>... Text HTML On Deletion: <Delete_Table id=“T1”> ... <Delete_List id=“E1”> ... Creating a List: <Create_List id=E1 ...> <In_Context>... 1) 2) 3)

  10. Low Level Heuristics (HL) • Identifying Special Structures in No WYSISYG Actions HTML HTML HTML under Model Conditions: <Condition id=C1 ...> User.Age=18 <HTML_Affected> Parapraph <HTML_Affected> ... HTML Iteration: <Iteration id=I1 ...> <list id=E1> <HTML_Affected> Parapraph <HTML_Affected> ... User.Age = 18 Iteration from a List of Elements <UL...> <li>... </UL>

  11. Constructor Primitives • Used for translating User Actions+Syntactic Context Information” into XML, in order to represent the final Monitoring Model • WYSISYG Constructor Primitives • <Style>, <Font_Applied>, <Font_Size_Applied>, <Header_Style_Applied> • <Create_Table>, <Delete_Table> • <Create_List>, <Delete_List> • <Insert_Single_HTML>, <Insert_HTML_Into_Table> • <Remove_Single_HTML>,<Remove_HTML_From_Table> • No WYSISYG Constructor Primitives • <Condition>, <Iteration>

  12. Monitoring Model <?xml version="1.0" encoding="UTF-8"?> <Monitoring_Model> <Remove_Single_HTML ID="1"> <Text_Affected><![CDATA[<p> DIJKSTRA (G, s)<br>INICIALIZAR (G, s)<br>Q = V[G]<br>while Q not empty do<br> u = EXTRACT_MIN (Q)<br>for v in Ady[u] do<br>RELAX (G, u, v) </p>]]></Text_Affected> <In_Context start_text="0" end_text="120"><![CDATA[DIJKSTRA (G, s) INICIALIZAR (G, s) Q = V[G] while Q not empty do u = EXTRACT_MIN (Q) for v in Ady[u] do RELAX (G, u, v)]]></In_Context> </Remove_Single_HTML > <Insert_Single_HTML ID="2"> <Text_Affected><![CDATA[<p> DIJKSTRA (G, s)<br>INICIALIZAR (G, s)<br>Q = V[G]<br>while Q not empty do<br> u = EXTRACT_MIN (Q)<br>for v in Ady[u] do<br>RELAX (G, u, v) </p>]]></Text_Affected> <In_Context start_text="12" end_text="172"><![CDATA[Solo grafos dirigidos con peso no negativo.]]></In_Context> </ Insert_Single_HTML > < Insert_Single_HTML ID=”3"> <Text_Affected><![CDATA[<br>]]></Text_Affected> <In_Context location="before" location_pos="2"><![CDATA[Procedure]]></In_Context> </ Insert_Single_HTML >

  13. Monitoring Model <Create_List ID=”4" nature="sorted" type="1" start="1"> <Text_Affected><![CDATA[DIJKSTRA (G, s) INICIALIZAR (G, s) Q = V[G] while Q not empty do u = EXTRACT_MIN (Q) for v in Ady[u] do RELAX (G, u, v)]]></Text_Affected> <In_Context><![CDATA[DIJKSTRA (G, s) INICIALIZAR (G, s) Q = V[G] while Q not empty do u = EXTRACT_MIN (Q) for v in Ady[u] do RELAX (G, u, v)]]></In_Context> <List_Items> <Item-1><![CDATA[DIJKSTRA (G, s)]]></Item-1> <Item-2><![CDATA[INICIALIZAR (G, s)]]></Item-2> <Item-3><![CDATA[Q = V[G]]]></Item-3> <Item-4><![CDATA[while Q not empty do]]></Item-4> <Item-5><![CDATA[u = EXTRACT_MIN (Q)]]></Item-5> <Item-6><![CDATA[for v in Ady[u] do]]></Item-6> <Item-7><![CDATA[RELAX (G, u, v)]]></Item-7> </List_Items> </Crate_List> <Style ID=”5" type="UNDERLINE" action="applied"> <Text_Affected><![CDATA[algoritmo]]></Text_Affected> <In_Context start_text="15" end_text="24"><![CDATA[El titular del algoritmo es:]]></In_Context> </Style> </Monitoring_Model>

  14. DESK Back-End • DESK Server-Side. Receives DESK Front-End Monitoring Model and process such XML Model to perform changes on web presentation • The user sends automatically to DESK Server-Side the Monitoring Model by using DESK Client-Side browser, then the system performs all the changes reflected on Monitoring Model. The feed-back to author is a special web page informing about the changes summary and asking the designer (if needed) information about ambiguous changes. Furthermore, events and errors are reported to the designer as well.

  15. XML DESK Front-End Desk Back-End DESK Back-End Monitoring Model DESK Summary Web Page XML Monitoring Model from DESK Front-End Applying High Level Heuristics HH Finding out Semantic Context Enriched Monitoring Model (Initial Monitoring Model + Semantic Context Information) Pegasus Models XML ++ Updating Models Looking out for Authorised User Managing Changes

  16. JSP XML High Level Heuristics (HH)(Finding out Semantic Context) • High Level Heuristics allows DESK Server-Side application to exactly find out where the changes will be located in Web Application Models. It uses information coming from Low Level Heuristics (<In_Context>) High Level Heuristics Server-Side Context Location Module Disambiguation Module Domain Model Context Search Presentation Model Context Search Constructing a Presentation Model Map Domain Object Location Free HTML Search and Recognition

  17. High Level Heuristics (HH) • Server-Side Context Location Module • Domain Model Context Search Processing change from Monitoring Model => Client-Side Context of changed is needed => Suppose the change is in Domain Model => but ... What in the Web Application is going to be affected by the change? Domain Model Domain Model Domain Model <AtomicFragment> DIJKSTRA (G, s) <BR> INICIALIZAR (G, s) <BR> Q = V[G] <BR> while Q not empty do <BR> u = EXTRACT_MIN (Q) for v in Ady[u] do <BR> RELAX (G, u, v)]]> </AtomicFragment> <Class name= "Algorithm" parent="Topic"> <Relation name="procedure" title="Procedure” ... <Algorithm ID="Dijkstra" TITLE= ”Dijkstra's Algorithm"> ... 1 2 3 Attribute of a Domain Object Attribute of a Relation Between Classes HTML Fragment in the Domain

  18. High Level Heuristics (HH) • Server-Side Context Location Module • Domain Model Context Search 1 <Context> <Found_In> <Class class_name=”Algorithm" id=“Dijkstra” attribute=“TITLE”/> </Found_In> </Context> 2 <Context> <Found_In> <Class class_name=”Algorithm" relation_name=“procedure” attribute=“tittle”/> </Found_In> </Context> 3 <Context> <Found_In> <Class class_name="AtomicFragment" path="AtomicFragment,procedure,prerequisites,Algorithm,items,Course,Domain"/> </Found_In> </Context>

  19. High Level Heuristics (HH) • Server-Side Context Location Module • Presentation Model Context Search • Based on a Explicit Representation of The Domain Object Information located in the Presentation Model (Presentation Model Map) that better allows for any change processed to be located in the Presentation Templates. Presentation Model Map Presentation Model <Presentation_Model class_name="Algorithm"> <Domain_Objects> <Domain_Object name="algorithm" from_domain_model_class="Algorithm" /> <Domain_Object name="prerequisites" from_domain_model_relation= "prerequisites" /> <Domain_Object name="procedure" from_domain_model_relation= "procedure" /> <Domain_Object name="proof" from_domain_model_relation= "proofOfCorrection" /> </Domain_Objects> <h1> <%= title %> </h1> } <%= prerequisites.title () %> <%= procedure.title () %> <%= prerequisites.tree () %> .......

  20. Presentation Model Map <?xml version="1.0" encoding="UTF-8"?> <Presentation_Model class_name="Algorithm"> <Domain_Objects> <Domain_Object name="algorithm" from_domain_model_class="Algorithm" /> <Domain_Object name="prerequisites" from_domain_model_relation="prerequisites" /> <Domain_Object name="procedure" from_domain_model_relation="procedure" /> <Domain_Object name="proof" from_domain_model_relation="proofOfCorrection" /> </Domain_Objects> <Another_Objects> <Another_Object name="title" type="String" from_class="Algorithm" from_attribute="TITLE" /> </Another_Objects> <Domain_Objects_Appearing> <Found object="prerequisites"> <Appearing><![CDATA[<%= prerequisites.title () %>]]></Appearing> <Surrounding_Tags><![CDATA[[<h3>]]]></Surrounding_Tags> </Found> <Found object="procedure"> <Appearing><![CDATA[<%= procedure %>]]></Appearing> </Found> <Found object="procedure"> <Appearing><![CDATA[<%= procedure.title () %>]]></Appearing> <Surrounding_Tags><![CDATA[[<h3>]]]></Surrounding_Tags> </Found> <Found object="proof"> <Appearing><![CDATA[<%= proof %>]]></Appearing> </Found> <Found object="proof"> <Appearing><![CDATA[<%= proof.title () %>]]></Appearing> <Surrounding_Tags><![CDATA[[<h3>]]]></Surrounding_Tags> </Found> <Found object="title"> <Appearing><![CDATA[<%= title %>]]></Appearing> <Surrounding_Tags><![CDATA[[<h2>]]]></Surrounding_Tags> </Found> </Domain_Objects_Appearing> </Presentation_Model>

  21. High Level Heuristics (HH) • Server-Sidce Context Location Module • Presentation Model Context Search • Domain Object Location Presentation Model Map is used in order to locate domain object types and definition present in Presentation Template ... <Found_In> <Class class name= "Algorithm" relation_name = "procedure" attribute=“tittle” /> </Found_In> ... <Appearing><![CDATA[<%= procedure.title () %>]]> </Appearing> DomainObject procedure = algorithm.getRelation ("procedure") ... <Domain_Object name="procedure" from_domain_model_relation="procedure" /> ... ... <Found object="procedure"> <Appearing><![CDATA[<%= procedure.title () %>]]> </Appearing> <Surrounding_Tags><![CDATA[[<h3>]]]> </Surrounding_Tags> </Found> <h3> <%= procedure.title () %> </h3> ... Enriched Monitoring Model Explicit Presentation Model Presentation Model (Template “Algorithm”)

  22. High Level Heuristics (HH) • Server-Side Context Location Module • Presentation Model Context Search • Domain Object Location • Free HTML Search and Recognition Once Domain Objects have been located, DESK uses Client-Side Context Information from Monitoring Model for applying changes. Free HTML is located using advanced search algorithms and processed as well <In_Context location=“before”> ... <In_Context location=“after”> ... <In_Context starts=15 ends=40> ... Enriched Monitoring Model Presentation Model (Template)

  23. High Level Heuristics (HH) • Disambiguation Module Aims at addressing the problem of changes involving multiple contexts ... <Context> <Found_in> <Class class_name=”Algorithm" attribute=“tittle” /> <Class class_name="AtomicFragment" path="AtomicFragment,procedure,prerequisites,Algorithm, items,Course,Domain"/> </Found_in> <Real_Context> <Class class_name=”Algorithm" attribute=“tittle” /> </Real_Context> </Context> ... Enriched Monitoring Model

  24. High Level Heuristics (HH) • Disambiguation Module If <Real_Context> exists => Automatic Disambiguation else => User Interaction is needed

  25. ... and Nowadays... DESK Server-Side Monitoring Model + Context Model XML ++ Finding out Context Changes Management (Enriched Monitoring Model) XML Monitoring Model HTML HTML Domain Model Presentation Model User Model Authorized User PEGASUS DESK Front-End Runtime System

  26. Improvements (September, October, 2002)

  27. Searching for Disambiguation • What dos it happen if we have a modification context like this? • This is the Dijkstra’s Algorithm • From : This is the <%=Title%> • Up to now DESK can not carry out this modification (i.e. Dijkstra’s Algorithm) by using usual searching an characterising algorithms • Solution: • Syntactic context in DESK Client-Side must codify block information as well as context-in-environment information. • We need: After (paragraph), before (paragraph) and into (paragraph together with start and end positions) at the same time, as well as word after (modification) and word before (modification) location • Now, the search-for-semantic algorithm located at DESK Server-Side must search as follow: • 1. Search the Domain Model for words before and after • This generates a list of occurrences (as Title attribute in Dijkstra Object_id and maybe several atomic fragments) • 2. Search the previously built on list for matching the related paragraph • This generates a more reduced and optimised list of, maybe, an only element location. If not => Ambiguity. DESK must ask the user for disambiguation. User’s previous answered questions will be taken into account for resolving similar ambiguous cases.

  28. DESK-H (DESK-History) • The main idea of DESK-H is to provide the user with a history of related modifications for any change made by user under DESK to be translate to any presentation language or template • Up to now, changes are applied to both Domain Model and Presentation Template. • Now, we only have to completely codify general purpose changes to Domain and a given (unknown) Presentation Model

  29. DESK-H (DESK-History) (II) • For providing such a DESK-History, we need: • Find out syntactic information about the changes at DESK Client-Side (as usual) • Find out semantics about previous syntactic information at DESK Server-Side (as usual) • Find out (Characterise) a Main Object of every change • The principal object witch modified object belongs to • This could be supplied by means of the URL or meta tag into HTML • The class of the previously mentioned object • This could be supplied by means of the URL or meta tag into HTML • The relation (path) from the Main Object to the current modified object • For carrying out this task, we need to locate the relationships of both modified object and context environment objects (by using after and before attributes), identifying the relationship with such objects belong to. • Sometimes this heuristic results ill-suite since there could be no context around the modified object (i.e. one only prerequisite in such a relation) => Ask the user for disambiguation

  30. Semantics at Client-Side • In the beginning, we claimed not to use any semantic at Client-Side. But nowadays we use semantics in Special Structures Module for identifying complex structures coming from Presentation dynamics and widget rendering. • From now onwards, we can assume that DESK either uses semantics or not for enhancing generality and transportability to another systems. • This way, DESK will try to find out semantics at Client-Side, but if not then it will attempt to find them out at Server-Side. Those semantics could be applied to all structures and block detection. • It is a fact that non-use of semantics increases ambiguity cases and makes worse the inference process results. • Anyway, we must provide a list of all cases that DESK can address in lack of semantics.

  31. Atomic Changes between Widgets • Automated atomic changes between widgets • By means of a agent-inspired monitoring, providing the user with editing assistance. • Configurable by creating a behaviour XML configuration file (it might be present in DESK front-end browser / Client Software) • The agent search in the Monitoring Model for actions upon conditions codified in the above mentioned file. • Use of suitable windows for adding elements to widgets in edition time, by double clicking the given widget • A further range of actions to be controlled/inspected by the Agent. • Examples • Automated change from Table to Combo Box and List (Relationship) • Automated change from Combo Box to Table • Automated change from Table to Tree

  32. Assistance in Edition

  33. Agent’s Configuration <Atomic_Changes precision_search_degree="10"> <widget type="Table" change_to="ComboBox&List"> <Condition action="Creation" to="ComboBox" /> <Condition action="Creation" to="List" /> <Condition action="Exists_Relation" from="Combo" to="List" /> <OR> <Condition action="Guided_Insertion" from="Table" to="ComboBox" min_items_to_inference="3" /> <Condition action="Copy_and_paste" from="Table" to="ComboBox" min_items_to_inference="3" /> </OR> <OR> <Condition action="Guided_Insertion" from="Table" to="List" items_to_inference="3" /> <Condition action="Copy_and_paste"_ from="Table" to="List" min_items_to_inference="3" /> </OR> </widget>

  34. Agent’s Configuration (y II) <widget type="ComboBox" change_to="Table"> <Condition action="Creation" to="Table" /> <OR> <Condition action="Guided_Insertion" from="ComboBox" to="Table" min_items_to_inference="3" /> <Condition action="Copy_and_paste" from="ComboBox" to="Table" min_items_to_inference="3" /> </OR> </widget> <widget type="Table" change_to="Tree"> <Condition action="Creation" to="Table" /> <Condition action="="Exists_Relation" from="Table" to="Tree" /> <Condition action="Elements_moved_out" from="Table" min_items_to_inference="3" /> <Condition action="Elements_automatically_sorted" to="Tree" /> </widget> ... </Atomic_Changes>

  35. Syntax Meaning • min_items_to_inference • Min number of items to be inserted, moved, etc. until the assistance window to reach. • precision_search_degree • to search from bottom to up to 10 previous Monitoring Model’s primitive actions • Guided_Insertion • Elements inserted using pop-up add-element windows by double clicking the widget • OR • Almost one of the conditions has to be true. It could be omitted if there is only a condition inside the OR block. • Exists_Relation • It means that elements are related by an ontology-defined relationship • It could be detected by checking the meta-information attributes present in each HTML structure (Table, List, etc.) and copied to The Monitoring Model

  36. Dealing with Ambiguities • The main idea is to codify generic possible ambiguities that can be appears during the inference process • What does it happens if there are more list elements than Table columns/rows? • If the first column has different attributes, Should the rest be copied to others cells? <widget type="List" change_to="Table"> <Condition action="Creation" to="Table" /> <Condition action="Copy_and_paste" from="Table" to="List" /> <Ambiguity condition="Table.dim.N < List.items.size" action="Table.add.columns(List.items.size-Table.dim.N)" default="Ask_user_for(N) " /> <Ambiguity condition="Table.dim.M < List.items" action=" Table.add.rows(List.items.size-Table.dim.M)" default="Ask_user_for(M)" /> <Ambiguity condition="Table.cell.attributes.Differ" action="Table.cell.copy.attributes" default="Ask_User_for_Acknowledgement" /> </widget>

  37. Iteration Patterns • Transforming any kind of widget into another one (e.g. a Table) is not an easy task • How does DESK has to infer the table generation? • Depending on where the user makes copy-paste to • Different cases • linear column motion (always in the same column) • linear row motion (always in the same row) • DESK has to search the Monitoring Model for correspondences between insertion into table columns/rows. • For making the whole insertions by him-self, DESK has to detect IterationPatterns. • Such patterns could be either parametrical, or maybe could be pre-defined inside the authoring tool. • Check out for different examples, such as List=>Table, Tree=>Table, ComboBox=>Table, and so on.

More Related