===== 080304 ===== Wykonano: * Zapoznanie się z częścią pracy magisterską Macieja Kwietnia i Jana Rachwalika dotyczącą GEF. * Zainstalowanie plug-inu GEF na platformie Eclipse * Uruchomienie przykładowego edytora, stworzenie przykładowego grafu w tym edytorze, przeglądnięcie kodu przykładowego edytora. * Zapoznanie się ze specyfikacją ARD+ zawartą w https://ai.ia.agh.edu.pl/wiki/hekate:bib:hekate_bibliography#gjn2008flairs-ardformal * Zapoznanie się z opisem systemu VARDA zawartego w https://ai.ia.agh.edu.pl/wiki/hekate:bib:hekate_bibliography#gjn2008flairs-ardprolog * Pobieżne przestudiowanie przykładu UServ zawartego w https://ai.ia.agh.edu.pl/wiki/hekate:bib:hekate_bibliography#gjn2008flairs-userv Powstałe wątpliwości: * Finalizacja. * Zbiór wszystkich możliwych operacji wykonywanych przez użytkownika. * Język opisu powstałego grafu: RGML? ATTML [[hekatedev:hekate_markup_language]] * Przestrzeń nazw. * Czy również implementacja drzewa TPH? Na ile bezpieczne w sytuacji cykli, split/merge, manual refactoring. * Liczba korzeni w drzewie, czy istnieje coś takiego jak korzeń? * XSD z opisem ARD+. * Co jak na końcu "liścia" jest Conceptual Attribute? Jaki wpływ na system? * Physical Attribute a XTT. * Attribute a Property. W prologu deklarowane oba. ===== 080318 ===== * [[hekate:varda]] - uruchomiono i przeanalizowano funkcjonalność. * Zapoznano się ze specyfikacją ATTML * Zapoznano się z UServ case study ===== 080415 ===== Planowano: * prototyp Zrealizowano: * Przeanalizowanie [[http://www.eclipse.org/articles/Article-GEF-diagram-editor/shape.html|Diagram Editor]] * Przeanalizowanie [[http://www.eclipse.org/articles/Article-GEF-editor/gef-schema-editor.html|Schema Editor]] * Rozpoznanie struktury framework'u GEF * Zainstalowanie EMF oraz GMF * Wykonanie tutorialu [[http://wiki.eclipse.org/index.php/GMF_Tutorial|mindmodel]] na podstawie [[http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmf/examples/org.eclipse.gmf.examples.mindmap/model/mindmap.xsd?root=Modeling_Project&view=markup&content-type=text%2Fvnd.viewcvs-markup&revision=HEAD|mindmodel.xsd]] ===== 080429 ===== Planowano: * model xsd, translacja do ecore * automatyczny edytor Zrealizowano: Dokument [[https://ai.ia.agh.edu.pl/wiki/_media/hekate:hml-test.xml?id=hekate%3Ahekate_markup_language&cache=cache|hml-test.xml]] poprawnie przechodzi [[http://www.xmlforasp.net/SchemaValidator.aspx|walidację]] przy użyciu powyższej definicji. Konwersji dokonano przy użyciu programu [[http://www.thaiopensource.com/relaxng/trang-manual.html|Trang]]. ===== 080527 ===== Edytor ARD powinien umożliwić tworzenie i edytowanie następujących elementów języka HML: * Property * Attribute * połączenia między elementami Property Okazuję się jednak, iż framework GMF nie jest na tyle elastyczny, aby stworzyć edytor o powyższych założeniach na podstawie modelu hml.xsd. Framework GMF bazuje na modelach Ecore. Model Ecore można utworzyć samemu lub też otrzymać na drodze konwersji ze schematu XSD Schema. Dokładny opis konwersji opisany jest w [[http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf|niniejszym dokumencie]]. Jedynym sposobem wpływania na mapowanie są tzw EAnnotation (str. 13) umieszczane w samym pliku xsd. W ten sposób można np zamienić atrybut IDREF na element, zmianę korzenia dokumentu albo zignorowanie danego elementu. Jednak adnotacje nie dają możliwości reorganizacji struktury elementów, zawierania się. Konwerter oprócz pliku Ecore zwraca także plik mapowania .xsd2ecore. Można w nim podglądnąć szczegóły mapowania. Sam konwerter nie daje się jednak skonfigurować. Konwersja jest jednoznaczna. Mówią o tym następująca odpowiedź programisty frameworku GMF. Matthew Rawlings wrote: > While reverse engineering a XSD to eCore I generate a .xsd2ecore file. > Having changed the mapping in the .xsd2ecore file how I can a re-run it from > inside Eclipse? > # From: Ed Merks # Date: Sat, 19 Aug 2006 18:01:31 -0400 Matthew, That file is produced only to reflect what the XSDEcoreBuilder does, i.e., the relationship between the input schema and the output Ecore. It's not used as input to drive anything else. Short of writing a derived XSDEcoreBuilder, the best way to affect the mapping is to use the annotations in described in: http://www.eclipse.org/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf Support for quite a few new annotations was added in 2.2 and are not yet documented. You'll note that the XML Schema information is recorded as EAnnotations and this annotation syntax can be used directly on any Ecore model to affect not only how instances of that model are serialized to XML but also to influence how that model itself is mapped to XML Schema when exported... _____ Ed Merks is a co-lead of the top-level Eclipse Modeling project as well as the lead of the Eclipse Modeling Framework project. He has many years of in-depth experience in the design and implementation of languages, frameworks and application development environments. He holds a Ph.D. in computing science and is a co-author of the authoritative "Eclipse Modeling Framework, A Developer's Guide" (Addison-Wesley 2003). He works for IBM Rational at the Toronto Lab. Problem stanowią połączenia między elementami w modelu hml.xsd. W przypadku Ecore, aby element A posiadał element B i mógł być z nim połączony bezpośrednim linkiem, to element B musi być bezpośrednim składnikiem elementu A. Na przykład: Jeśli natomiast jeśli B nie jest składnikiem elementu A, to niemożliwe jest utworzenie bezpośredniego połączenia między nimi. Gdybyśmy chcieli mieć możliwość tworzenia i edytowania Property jak i Attribute musielibyśmy wybrać korzeń pliku element Hml jako korzeń modelu Ecore. Tylko ten element "zawiera w sobie" elementy zarówno Property jak i Attribute. Ale wtedy aby stworzyć pojedynczy element Property z jednym Atrribute'm musielibyśmy wykonać następujący szereg czynności: - dodać z Palety element PropertySet - dodać z Palety element Property i połączyć go linkiem z PropertySet (relacja posiadania) - dodać z Palety AttributeSet - dodać z Palety Attribute i połączyć go linkiem z AttributeSet - dodać z Palety Attref i połączyć go z Property oraz z Attribute Jest to sprzeczne z oczekiwaniami stawianymi edytorowi graficznemu. ---- Próby utworzenia edytorów: * Nie udało się utworzyć za pomocą standardowych narzędzi GMF edytora na podstawie hml.xsd. * Dokonano próby utworzenia edytora wszystkich elementów (bez żadnej customizacji) za pomocą pluginu do GMF o nazwie [[http://dynamicgmf.sourceforge.net/|dynamic gmf]]. Ten plugin ma w założeniu dać możliwość wygenerowania edytora jedynie przez wybranie pliku xsd. Pojawiał się jednak błąd wewnętrzny programu "Null pointer exception". Takiego błędu nie było gdy użyłem pliku [[http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmf/examples/org.eclipse.gmf.examples.mindmap/model/mindmap.xsd?root=Modeling_Project&view=markup&content-type=text%2Fvnd.viewcvs-markup&revision=HEAD|mindmap.xsd]]. Sądzę, iż obecność elementów IDREF mogła się do tego przyczynić. ---- Wnioski: * Model hml.xsd nie pasuje do frameworku GMF. * Uważam, że prościej i przejrzyściej byłoby stworzenie nowego modelu Ecore uwzględniając przy tym tylko te elementy, które są potrzebne w diagramie ARD. * Automatycznie generowany plik xml nowego edytora można by przy pomocy utworzonego pliku XSLT przekształcić do pliku kompatybilnego z hml.xsd. ===== 080610 ===== Moja propozycja ard.xsd (wersja 1.0) W powyższym modelu brakuje TPH oraz całego XTT. W przypadku TPH jestem na etapie szukania możliwości automatycznej generacji części xml'a odpowiadającej za TPH. Jednak z powodu dużego zautomatyzowania GMF'a nie wiem na ile to będzie możliwe lub kiedy uda mi się to zrobić. Screen z prostego edytora ard oraz odpowiadający mu plik xml. Przykład 1: Diagram Ard {{http://hyper.ia.agh.edu.pl/~dudekm/zdj/przykladowy_edytor_1.jpg}} Wygenerowany XML Sprawdzono zgodność pliku xml ze schematem xsd. ---- Perspektywy * XSLT? * Automatyczne TPH * Menu kontekstowe na operacje Finalizacji i Splitu?