Welcome Guest Search | Active Topics | Members | Log In

Interfejsy a perspektywy - szkic raportu Options · View
habela
Posted: Tuesday, January 25, 2005 11:04:49 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
OK. Ja natomiast zachęcam wszystkie osoby, które zainteresowały się tym tematem do sygnalizowania problemów "przyległych", które powinny zostać uwzględnione w obszerniejszym raporcie ntt. oraz mogłyby być wyeksponowane jako pierwszoplanowy wątek w jednym lub dwóch artykułach "pochodnych" w stosunku do tutaj wystawionego.
Pierwsze co się nasuwa to:
- sprecyzowanie sposobu zarządzania schematami dla poszczególnych użytkowników;
- walory oraz ograniczenia reprezentowanego tu podejścia do modułów (dosyć duża wzajemna autonomia - patrz środowiska rozproszone, kwestie zarządzania zależnościami);
- rozwinięcie koncepcji o mechanizmy schematu służące konstruowaniu federacji;
- inne...?
stencel
Posted: Saturday, January 29, 2005 1:26:44 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Oto nowa wersja artykulu. Caly przeoralem pod wzgledem prostoty zdan. Nie powinny byc dluzsze niz dwa wiersze.

Natomiast merytorycznie (dodatkowo poza poprzednim dlugim moim postem):

1. Jakos dokonczylem bullet "Operations" w sekcji "Sorting out Core Notions", ale nie wiem, czy zgodnie z intencjami Piotra. Do sprawdzenia.

2. Usunalem cala czesc "export" z Samples.contact. Skoro w naglowku piszemy, contact supports contactData, to po co w srodku jeszcze raz powtarzac tresc tego samego eksportu? To juz nie dwa ale TRZY razy ta deklaracja bedzie powtorzona, a to jest juz nieakceptowalne przez nikogo.

Dalsze prosby i watpliwosci:

a) Popraw Piotrze ten rysunek, tak jak zgodziles sie w jednym z poprzednich postow. To drobna poprawka.

b) Czy w eksportach przy assocjacjach tez piszemy reverse? Bo mi sie wydaje, ze sprawa zwiazku odwrotnego jest kwestia implementacyjna (wiezy spojnosci) i w interfejsie nie powinna wystepowac. Co Wy na to? Tak wiec np:

Code:
module Samples.Departments {

  class Department supports BusinessUnit {
    export {
      ...
      employs [0..*] : ref Employee;
      ...
    }
    ...
    employs [0..*] : ref Employee inverse worksIn;
    ...
  };
};

File Attachment(s):
paper_EncapsulationUsingViews.doc (83kb) downloaded 45 time(s).


habela
Posted: Saturday, January 29, 2005 2:06:28 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Dzięki!
Będę w stanie zająć się tekstem wieczorem. Poprawię też rysunek (może mi się uda bez przerysowywania w innym narzędziu, bo jak Szef słusznie zauważył w aktualnej postaci jest nieczytelny - zbyt drobne znaki).
stencel wrote:
2. Usunalem cala czesc "export" z Samples.contact. Skoro w naglowku piszemy, contact supports contactData, to po co w srodku jeszcze raz powtarzac tresc tego samego eksportu? To juz nie dwa ale TRZY razy ta deklaracja bedzie powtorzona, a to jest juz nieakceptowalne przez nikogo.

Tu jest jeden subtelny problem. Otóż definicja perspektywy (czyli takiej virtual feature) z założenia może tworzyć interfejs inny niż oferowany przez jakikolwiek obiekt konkretny w bazie danych. To znaczy, że virtual feature zgodna z Samples.contact miałaby prawo udostępniać na zewnątrz jeszcze coś więcej niż contactData. Innimi słowy Samples.contact można sobie wyobrazić jako źródło obiektów klasy Samples.contact implementującej interfejs contactData.
Moje pytanie brzmi: gdybyśmy zdecydowali, że Samples.contact oferuje jeszcze dodatkowo np. podobiekt stringowy "website", to czy byłoby intuicyjne, aby umieścić w niej export który będzie zawierał tylko deklarację tego "atrybutu".
Mam nadzieję, że jest to akceptowalne, bo zgadzam się z argumentem Krzyśka, że warto usunąć tę nadmiarowość.
stencel wrote:
b) Czy w eksportach przy assocjacjach tez piszemy reverse? Bo mi sie wydaje, ze sprawa zwiazku odwrotnego jest kwestia implementacyjna (wiezy spojnosci) i w interfejsie nie powinna wystepowac. Co Wy na to?

Dołączam się do pytania. Osobiście zaś głosowałbym raczej za zostawieniem, bo to że dwa linki z przeciwległych exportów są ze sobą sprzężone stanowi istotną informację dla użytkownika bazy danych.
subieta
Posted: Saturday, January 29, 2005 8:38:04 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
habela wrote:
Osobiście zaś głosowałbym raczej za zostawieniem, bo to że dwa linki z przeciwległych exportów są ze sobą sprzężone stanowi istotną informację dla użytkownika bazy danych.


Też bym to zostawił, rowniez z tego powodu, ze sprawa ma zaszłość w ODMG.

Ten element wskazuje na to, ze interfejs jest czyms wiecej niz typ, w szczegolnosci moze specyfikowac wszystkie informacje niezbedne do zrozumienia przy programowaniu aplikacji. Przypomnę, ze oryginalnie u Parnasa oraz w Modula-2 do takiego "interfejsu" nalezala takze lista importowa, zaś w przypadku metodyki BON i jezyka Eifel do takiego "interfejsu" naleza takze wszelkie asercje, w tym pre- i post- conditions (czyli cos w rodzaju integrity constraints). Jest to cos, co raczej nie wejdzie do tego artykulu, ale w zwiazku z tym rysuja sie juz powody do nastepnych jego mutacji.
stencel
Posted: Monday, January 31, 2005 1:32:08 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
habela wrote:
Moje pytanie brzmi: gdybyśmy zdecydowali, że Samples.contact oferuje jeszcze dodatkowo np. podobiekt stringowy "website", to czy byłoby intuicyjne, aby umieścić w niej export który będzie zawierał tylko deklarację tego "atrybutu".

Moim zdaniem tak. Jest to intuicyjne. To co klasa eksportuje jako klasa (wtedy gdy mamy referencje do obiektu klasy po prostu a nie do zadnego interfejsu) to suma implementowanych przez nia nazwanych eksportow (zadeklarowanych zewnetrznie lub wewnetrznie) plus export defaultowy (bez nazwy). Mysle, ze dla uzytkownikow na pewno nie byloby akceptowalne powtarzanie informacji ze a : b jest w klasie i eksportowane przez eksport C trzy razy:

1. w czesci implementacyjnej klasy.
2. w czesci "nienazwany export" klasy.
3. w eksporcie C, ktory jest przez te klase supported.

habela wrote:
Dołączam się do pytania. Osobiście zaś głosowałbym raczej za zostawieniem, bo to że dwa linki z przeciwległych exportów są ze sobą sprzężone stanowi istotną informację dla użytkownika bazy danych.

Uznaje argumenty Szefa. Zreszta sam mialem watpliwosci (bo tego z pracy nie usunalem). Zostawiamy inverse w eksportach.
stencel
Posted: Monday, January 31, 2005 1:36:49 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
W imieniu Krzysia Kaczmarskiego wrzucam jego wersje pracy i komentarz:

Przejrzałem tekst o interfejsach.

Wstawiłem z milion przecinków i znalazłem wiele błędów gramatycznych. Wszystkie zmiany i podejrzane miejsca zaznaczyłem na zółto. Dodatkowo w kilku miejscach znajdziecie moje komentarze.

Sądzę, że tekst jest w pierwszej części nieco przegadany i trzeba by go skrócić. Chyba trzeba więcej przykładów i lepszego wyjaśnienia składni tego, jak działają wirtualne atrybuty.

File Attachment(s):
paper_EncapsulationUsingViews_KK.doc (93kb) downloaded 46 time(s).


habela
Posted: Tuesday, February 01, 2005 12:25:38 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Przesyłam wersję po moich poprawkach.
Czytałem cały tekst, choć z przyczyn czasowych nie w pełni wnikliwie, więc coś mogło mi umknąć.
Generalnie:
- wprowadziłem parę dyktatorskich (bo bez zaznaczenia i śledzenia zmian) korekt. Sprawa dotyczy zwłaszcza uczynienia abstraktu bardziej abstrakt-cyjnym ;-) i przesunięcia wobec tego części objaśnienia specyfiki bazodanowych interfejsów do Introduction (BTW: skojarzyłem teraz, że sprawę pominięcia przywilejów użytkownika można podnieść w tekście w miejscu krytyki ODMG);
- poprawki stylistyczne - starałem się rozstrzygnąć poprawki od Krzysztofa K. W paru miejscach, gdzie nie jestem pewien spraw językowych, zostawiłem podświetlone na żółto, względnie dałem komentarz.
- zmiany od Krzyśka S. są zgrabnie sformułowane, choć musiałem w kilku miejscach interweniować, bo zmieniały czasem sens danego zdania. Oczywiście w takich sytuacjach starałem się nie powracać do swoich oryginalnych sformułowań, tylko do czegoś mniej podatnego na błędną interpretację.

Abstrahując od kwestii ostatecznego czyszczenia tekstu przed jakąś wysyłką, oczekiwałbym teraz:
- rozstrzygnięcia tych paru kwestii natury językowej zaznaczonych w tekście;
- propozycji tematów do rozwinięcia (w tym samym tekście w perspektywie dużego raportu IPI oraz jako "pakietów" problemów do podjęcia w osobnym artykule / osobnych artykułach);

Postaram się jeszcze wrócić za parę dni do tego tekstu, jak dostanę uwagi od Szefa.

File Attachment(s):
paper_EncapsulationUsingViews_PH.doc (96kb) downloaded 45 time(s).


michal
Posted: Wednesday, February 02, 2005 2:15:57 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
mam dwie uwagi:

1. o ile mi wiadomo, to nie udalo sie przykryc slowka protected,
a ten mechanizm chyba jest dosc przydatny.

moja propozycja to specyfikowanie interfejsu po ktorym
dziedziczymy w podklasie

class Pracownik inherits Osoba(ICzescOsoby) {
...
}

2. tak cos czuje ze fan relacyjnych baz danych moze sie
doczepic do tego, ze w naszych modulach tracimy cos,
co sie nazywa niezaleznoscia danych od aplikacji ...
stencel
Posted: Wednesday, February 02, 2005 4:57:36 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
michal wrote:
o ile mi wiadomo, to nie udalo sie przykryc slowka protected, a ten mechanizm chyba jest dosc przydatny. Moja propozycja to specyfikowanie interfejsu po ktorym dziedziczymy w podklasie

Code:
class Pracownik inherits Osoba(ICzescOsoby) {
...
}



Michale, jak zwykle jestes wyjatkowo enigmatyczny. Pisz prosze zawsze szerzej, zeby takie ciemniaki jak ja mogly Cie zrozumiec.

Definiowanie interfejsow odbywa sie na kazdym poziomie hierarchii dziedziczenia, przy czym skladnia wymyslona przez Piotra jest inna:

Code:
class Pracownik extends Osoba supports ICzescOsoby {
...
}


Czy moze chodzilo Ci o to, ze jesli Osoba supports ICzescOsoby, to wcale nie musi byc tak, ze Pracownik supports ICzescOsoby i trzeba to jawnie napisac? Tylko trzeba pamietac, ze jest to contra zasadzie zamienialnosci (substitutibility).

michal wrote:
tak cos czuje ze fan relacyjnych baz danych moze sie doczepic do tego, ze w naszych modulach tracimy cos, co sie nazywa niezaleznoscia danych od aplikacji ...


No mysle, ze jak bedzie chcial, to zawsze sie przyczepi (oni tak maja). Fan, o ktorym piszesz, przy odrobinie dobrej woli zdefiniowalby sobie oddzielnie moduly ze skladem danych i oddzielnie moduly z definicjami eksportow i klas. Wtedy mialby swoja niezaleznosc. A jak ktos chce te dwie rzeczy sobie w module polaczyc, to dlaczego mu tego zabraniac?

W przeciwnym wypadku trzeba by wprowadzic dwa pojecia: modul i pakiet. A z kolei to rozroznienie dla wielu (takich jak ja) bedzie niezrozumiałe i nienaturalne.
stencel
Posted: Wednesday, February 02, 2005 5:04:36 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Nie nanosze poprawek bezposrednio na tekscie, zeby nie robic zamieszania. Zakladam ze Piotr jest jego wlascilem, a teraz odnosze sie do poszczegolnych komentarzy w tekscie:

[PH1] Proponuje (dzielimy to gargantuiczne zdanie na czesci):

"That is, virtual objects are accessed and manipulated the same way as stored objects. Interfaces of virtual objects are indistinguishable from interfaces of stored objects. Moreover, the encapsulation works exaclty the same for these two kinds of objects."

[Strona 1] upcasted -> upcast, a najlepiej "cast up"

Wybor miedzy "upcast" a "cast up" pozostawiam reszcie. To zalezy od tego, co widzieliscie w literaturze przedmiotu. Jesli "upcast" jest czesto uzywany, to jest OK.

"cast" jest nieregularny. Zarowno past simple jak i past participle to po prostu "cast".

"casted" to paskudny blad ortograficzno-gramatyczny, ktory nas zdyskwalifikuje w oczach recenzenta native-speakera.

[PH2] OK. tangles -> mixes

[KK3][PH4] Zdecydowanie "a means". Tak jest poprawnie. Zajrzyjcie do mojego ulubionego poradnika gramatycznego: http://www.bartleby.com/64/pages/page118.html

[KK5] Nieprawdą jest jakoby nie dalo sie przechowywac identyfikatora wirtualnego. A dlaczego nie? Przeciez on zawiera seed z ewentualnymi (trwalymi!) referencjami do obiektow trwalych i (trwaly!) identyfikator perspektywy.

Jesli zakladamy, ze identyfikatory obiektow trwalych sa niezmienne (a musimy to zalozyc), to zapisywanie identyfikatora wirtualnego nie napotyka zadnych przeszkod.

[KK7][PH8] Glosuje za odwolaniami postulowanymi przez KK. Nie ma sie co chowac. Nikt nie zabroni dac tej samej referencji w artykule na temat "importo/eksporto".

[Ta sama strona co [PH8]] Zolte przecinki zostaly zolte chyba przez pomylke. Dla mnie sa OK.

[PH9] Znow skonsultowalem sie z poradnikiem gramatycznym: http://www.bartleby.com/64/pages/page96.html (znajdzcie "firstly"). Wynika z niego ze obie formy sa OK:

GrammarGuide wrote:
Both first and firstly are well established to begin an enumeration: Our objectives are, first (or firstly), to recover from last year’s slump. Whichever you choose, however, be consistent and use parallel forms in the series, as in first … second … third or firstly … secondly … thirdly.


Ja wole first/second/etc i dlatego pozmienialem, ale sie nie upieram. W kazdym razie jest krotsze. Na pewno jest poprawne.

[PH10] No jasne, sciemnilem. Ale nie jest dobrze gramatycznie, bo powinno byc: "cover A with B" a jest "cover with B A". Nie mowiac juz o "view definition", ktore nie jest tym samym co "definition of a view". "View definition" to "definicja perspektywowa czegos", np. "view definition of a variable" ma sens i jest to "perspektywowa definicja zmiennej". Dlatego piszmy "definition of view" gdy mamy na mysli "definicje perspektywy" a nie "definicje perspektywowa". Ostatecznie (po uproszczeniach):

"The assumptions from previous subsection allow covering all externally visible details of updateable object views with interface definitions."

Łyknijcie to prosze, bo obecne zdanie jest koszmarne.

[PH11] No jasne. Tu jest wbrew gramatyce. A ja bym to zdanie jeszcze bardziej uproscil:

"The content of the module Samples.Company is exclusively metadata oriented."

To co wycialem nic nie wnosi. Wiec won. Ogolnie zasada jest taka, ze czytamy zdanie i wycinamy wszystko, co wydaje sie zbedne. Jesli po wycince sens zdania jest taki sam, to jest OK.
michal
Posted: Wednesday, February 02, 2005 5:16:33 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
Quote:
Michale, jak zwykle jestes wyjatkowo enigmatyczny. Pisz prosze zawsze szerzej, zeby takie ciemniaki jak ja mogly Cie zrozumiec.


e, nie. wycofuje sie z tego. obie moje watpliwosci
byly delikatnie mowiac nieprzemyslane...
habela
Posted: Thursday, February 03, 2005 11:05:28 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Co do podanych poprawek Krzyśka S., to nic w międzyczasie nie zmieniałem - możesz więc je nanieść na dokument i ewentualnie tu wystawić.
Co do protected, to można się zastanowić, ale o ile nie okaże się to pragmatycznie niezbędne, to warto wyciąć (tak się na to zapatruje Szef, ale można popytać).
Czy ktoś z Was dysponuje w najbliższych dniach determinacją, pomysłem i czasem aby sporządzić szkic jakiegoś mutanta? Proponuję założyć nowy wątek obok oraz uporządkować zestawienie tematów i pomysłów "przyległych".
stencel
Posted: Thursday, February 03, 2005 12:36:25 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
habela wrote:
Co do podanych poprawek Krzyśka S., to nic w międzyczasie nie zmieniałem - możesz więc je nanieść na dokument i ewentualnie tu wystawić.


Zrobione. Dokument w zalaczeniu. Wprowadzilem wszystko co opisalem, bo nikt nie protestowal.

habela wrote:
Czy ktoś z Was dysponuje w najbliższych dniach determinacją, pomysłem i czasem aby sporządzić szkic jakiegoś mutanta? Proponuję założyć nowy wątek obok oraz uporządkować zestawienie tematów i pomysłów "przyległych".


Ja dysponuje, ale proponuje inny tryb dzialania. Konkretnego mutanta szykujmy juz pod konkretna konferencje. Moim zdaniem nie ma co walczyc z raportem IPI bo on i tak sie nie liczy w dorobku. Na razie na liscie konferencji jest ADBIS i VLBD. Kto da wiecej? Zapytam Szefa mailowo, bo chyba nie czyta on tego watku on-line.

Tak wiec przygotowywanie mutanta juz pod konkretna ustalona konferencje.

Tematow potencjalnych mutantow jest wiele:

1. Klasy i dziedziczenie (teraz nie ma).
2. Dynamiczne role.
3. Wiecej o atrybutach wirtualnych.
4. Eksporty nazwane/nienazwana/in-line/out-of-line.

Cztery mutanty to przyzwoicie bedzie. I kazdy z nich doda cos do metamodelu.

File Attachment(s):
paper_EncapsulationUsingViews_PH_KS.doc (84kb) downloaded 51 time(s).


KK
Posted: Thursday, February 03, 2005 2:42:13 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
stencel wrote:

[KK5] Nieprawdą jest jakoby nie dalo sie przechowywac identyfikatora wirtualnego. A dlaczego nie? Przeciez on zawiera seed z ewentualnymi (trwalymi!) referencjami do obiektow trwalych i (trwaly!) identyfikator perspektywy.


No tak, ale dane do ktorych odnosi sie wirtualny indentyfikator moga nagle bez ostrzezenia przestac istniec... czy nie?
W seedzie jest to co sie tam wsadzi, ale najczesciej sa to identyfikatory obiektow wyjsciowych (bo wtedy ma to jakis sens).
Jesli mamy np wirtualnego BogategoPracownika wskazujacego tak naprawde przez seed na obiekt Krzysztof, a ktos Krzysztofa zwolni, to na co bedzie pokazywal seed ?

Z tego co zrozumialem Szefa, to cala zabawa polega na tym, by nie przechowywac stanu w wirtualnych obiektach. Wtedy dochodzi nam ich nieustanne poprawianie jak przy materializowalnych perspektywach. A my tego chcemy uniknac. Dlatego nie mozemy przechowywac wirtualnych identyfikatorow, tylko je konsumowac natychmiast po stworzeniu.

stencel
Posted: Thursday, February 03, 2005 2:49:31 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
KK wrote:
No tak, ale dane do ktorych odnosi sie wirtualny indentyfikator moga nagle bez ostrzezenia przestac istniec... czy nie? W seedzie jest to co sie tam wsadzi, ale najczesciej sa to identyfikatory obiektow wyjsciowych (bo wtedy ma to jakis sens).
Jesli mamy np wirtualnego BogategoPracownika wskazujacego tak naprawde przez seed na obiekt Krzysztof, a ktos Krzysztofa zwolni, to na co bedzie pokazywal seed ?


No to nie widze tu roznicy miedzy obiektami skladowanymi i wirtualnymi. Przeciez jesli w tej sytuacji mam gdzies na pliku zapisaną referencje do obiektu Krzysztof i ktos go skasuje, to tez zostaje mi referencja donikąd. Tak naprawde dzieje sie wtedy to samo, co z BogatymPracownikiem.
KK
Posted: Thursday, February 03, 2005 2:58:29 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
Podrzucam kilka pozycji literatury, ktore moga sie przydac do Related Research (nie tylko w tym temacie)

[HEIJ96] W. Heijenga. View definition in OODBS without queries: a concept to support schema-like views. In Doct. Cons. 2nd Intl. Baltic Wg on Databases and Information Sys-tems, Tallinn (Estonia), 1996.
http://citeseer.ist.psu.edu/heijenga96view.html

[HEIJ95] W. Heijenga. Operational and Structural View Models in ooDBS: Differences,
Fields of Applications, and Integration. Cadlab Report 3/95, Cadlab, Paderborn, 1995.
http://citeseer.ist.psu.edu/heijenga95operational.html

[Abit00] S.Abiteboul. On Views and XML. Proc. of PODS Conf., 1999, 1-9
http://citeseer.ist.psu.edu/abiteboul99views.html

[ABS96] S. Amer-Yahia, P. Breche, C. Souza dos Santos. Object Views and Updates, BDA’96, France
http://citeseer.ist.psu.edu/amer-yahia96object.html
KK
Posted: Monday, February 07, 2005 12:14:21 PM
Rank: Advanced Member

Joined: 12/7/2004
Posts: 226
Points: 30
Jeszcze kilka publikacji o integrowaniu danych przy pomocy globalnego schematu i danych wirtualnych.
(Motywacja do naszych interfejsow)

D. Calvanese, E. Damaggio, G. De Giacomo, M. Lenzerini, R. Rosati. Semantic Data integration in P2P systems. Proceedings of the International Workshop on Databases, Information Systems, and P2P Computing, Berlin, Germany, September 2003.
http://www.dis.uniroma1.it/%7Elenzerin/progetti/hyper/paper.ps.gz -- warto przeczytać Introduction.


Source Integration in Data Warehousing (1997) Diego Calvanese, Giuseppe De Giacomo, Maurizio Lenzerini, Daniele Nardi, Riccardo Rosati
DEXA Workshop
http://citeseer.ist.psu.edu/137885.html

Information integration: Conceptual modeling and reasoning support
# Proc. of the 6th Int. Conf. on Cooperative Information Systems (CoopIS-98), pages 280-291, 1998. D. Calvanese, G. De Giacomo, M. Lenzerini, D. Nardi, and R. Rosati,
http://www.dblab.ntua.gr/%7Edwq/CoopIS-98_dwq.pdf -- Warto dotrzec do "Comparison with existing systems"

Generalnie polecam uwadze: Data Warehouse Quality http://www.dbnet.ece.ntua.gr/~dwq/
stencel
Posted: Wednesday, February 09, 2005 4:49:47 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Oto moja propozycja wystapienia konferencyjnego na DEXA:

http://www.dexa.org/dexa2005/index.php?include=main.php

Cialem okrutnie, ale i tak jest wiecej niz 10 stron. Mysle, ze recenzenci sie nie obraza i wytnie sie potem.

Deadline sa daleko, bo do 26 lutego musimy zglosic prace, a do 19 lutego abstract. Mysle, ze abstract jaki jest mozna w kazdej chwili zglosic, wiec wiaze na tylko termin 26 lutego.

Prosze wszystkich wspolautorow (dodalem Michala zgodnie z nasza korespondencja) poza Szefem o zglaszanie przez forum konstruktywnych poprawek. Wlasciecielem tekstu jestem ja i to ja je bede wprowadzal. Chce bysmy na weekend mogli przekazac te prace do obrobki Szefowi.

Szef mialby wtedy prawie dwa tygodnie na dopieszczenie tego artykulu.

My zaś w tym czasie nie zasypiamy gruszek w popiele, tylko smarujemy prace na adbis i vldb (deadliny wkrotce, ale zdazymy). Musimy szybko ustalić oś tych artykulów. Propozycja:

VLDB = podkreslamy dynamiczne role.
ADBIS = podkreslamy dziedziczenie i skupiamy sie na przykladach tak, zeby pokazac z dziedziczeniem wszystkie mozliwe warianty opisane na koncu punktu 4.3 aktualnego wystapienia.

Dyskusja musi byc rzeczowa i krotka bo deadliny nie sa tak daleko. Zapraszam.


File Attachment(s):
dexa-interface.doc (71kb) downloaded 44 time(s).


habela
Posted: Friday, February 11, 2005 10:44:22 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Krzyśku - wyrazy uznania za prace redakcyjne i skróty. Naprawdę bardzo dobrze się to czyta!
Na żadne rozwinięcia zestawu bibliografii się niestety nie zdobyłem (brak czasu) - ale z uwagi na specyfikę sposobu przedstawienia nie odczuwam w tym tekście specjalnego deficytu pod tym względem.
Komentarzy jest tylko kilka i są bardzo drobne, więc wysłałem tylko do właściciela master copy.
Może kolejną wersję tego pliku (albo jeszcze następną - po poprawkach Szefa) będzie warto wystawić w tym miejscu.
stencel
Posted: Saturday, February 12, 2005 12:41:02 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Piotrze, oto tekst po (wszystkich sensownych) Twoich sugestiach. Uwzglednilem je wszystkie (sprawdz, czy tak jak Ci lezy). Dzieki za przejrzenie.

Do pozostalych wspolautorow: przejrzyjcie to, bo w poniedzialek nieodwołalnie idzie to do ostatecznej obróbki by Szef.

File Attachment(s):
dexa-interface_KJS_2.doc (72kb) downloaded 51 time(s).


Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.238 seconds.