Internetes Csoportmunka a Tudományos Együttműködés

Eredeti által Jon Udell, http://jonudell.net/GroupwareReport.html

Internetes azért találták fel, hogy a tudósok számítógépes hálózatokat használhassanak az együttműködéshez, azaz dokumentumokat cseréljenek, megbeszéljék őket, koordinálják a munkát, kollektív tudást hozzanak létre és publikáljanak. Más szóval, ez egy csoportos alkalmazás volt.

Annak ellenére, hogy a népszerűsége a Web — vagy talán, mert a népszerűség — még nem teljesítette az eredeti küldetést. A mai háló inkább olyan, mint egy kényszerházasság az elektronikus publikálással és sugárzott TV vel, mint egy megtervezett megoldás a csoportos együttműködésre. Igaz, hogy az Internet felhatalmazza a mai dolgozó tudóst olyan módon, amiről csak egy évtizede álmodott. Ennek használata azonban gyakran a Web előtti idiómákban és szokásokban gyökerezik, részben azért, mert nem használjuk ki teljes mértékben a mai internetes kommunikációs eszközöket, de főleg azért, mert még mindig hiányoznak a kulcsfontosságú eszközök és infrastruktúra. Fontolja meg a rutin napi tevékenységek egy dolgozó tudós körülbelül 2000:

Szervezek egy találkozót egy kollégákkal. A találkozó szervezője e-mailben felveszi a kapcsolatot a célcsoporttal. Az idő és a helyszín megtárgyalása egy unalmas e-mail-adatsorozatot foglal magában, amely magában foglalja mind a strukturált adatokat (elfogadás/elutasítás/elhalasztás), mind a strukturálatlan kommunikációt (menetrend-beállítás, politika). Az Internet kizárólag üzenetküldésre használható. Az üzenetküldő szoftver nem értik az esemény-ütemezési jegyzőkönyv nem rögzíti, vagy képviseli a konszenzus a csoport, de nem pajzs résztvevők az alacsony szintű üzenet flow annak érdekében, hogy a figyelmet az eredménye. Az értekezlet szervezőjének fel kell dolgoznia a nyers üzenetáramlást, minden értelmes szoftvertámogatás nélkül.

Természetesen, a hagyományos ütemezési viselkedés — beugrani az emberek irodájába, felhívni őket a telefonon — sosem volt automatizálható a szoftver. De ahogy egy tudós interjút készített a jelentés megjegyezte, vágyakozva, hogy kevésbé számít, amikor a személyi asszisztensek voltak elérhető, hogy ezeket a házimunkát. Manapság nehéz ilyen asszisztenst találni. Így elvárjuk, hogy a Web nem csak “csinálni a dolgokat gyorsabban”, hanem “csinálni több dolgot.”

Kérdések megvitatása egy csapat kollégával. Ha a csoportok nem tudnak szemtől szembe találkozni, a legjobban finanszírozott élvezheti a videokonferencia lehetőséghez való hozzáférést. Mások a konferenciahívásokra támaszkodnak. De a valós idejű video és hangkonferencia üzemmódokat mindig írásos kommunikációval kell bővíteni. E-mail a mód a választás, de sok okból teszi egy rossz eszköz a csoport vita. Amikor az üzeneteket a csapat tagjai egyszerűen leközlik, nincs központi átirat, és a társalgási téma könnyen elveszhet. Amikor az üzeneteket e-mail álneveken vagy listservs-en keresztül továbbítják, a dolgok egy kicsit jobbak, de amint látjuk, ezek a megosztott terek nem szervezik meg a csoportüzeneteket a leghatékonyabb módon.

A munkatársak tevékenységeinek nyomon követése az Ön saját és kapcsolódó területein. Tudományos együttműködésben mindenkinek más dolgával kell törődnie. Nagy figyelmet fordít arra, amit a közvetlen kollégái csinálnak, és legalább próbálja tartani a kapcsolatot a távoli kollégákkal és a kapcsolódó tudományágakkal. Köszönhetően az Internet a probléma itt már nem hiányzik az információ. Épp ellenkezőleg. Több információ áraszt el minket, mint amennyit fel tudunk dolgozni. Sok jön, újra, formájában torrent e-mail. “Szükségem van, hogy csatlakozzon néhány további listák,” mondta az egyik tudós interjúban ezt a jelentést, “de nem tudom kezdeni, hogy lépést tartson azokkal, már vagyok.”

Egy tudományos tanulmány publikálása. Általában a szerző írja a tervezetet a Microsoft Word, vagy, ha matek-intenzív, FrameMaker vagy TeX. Gyakran, ő vagy ő, majd e-maileket a draft kritikusok. A válaszok a dokumentum módosítási jelöléssel (Word esetén) ellátott változatai, illetve a dokumentum egyes részeire vonatkozó e-mailek formájában jelennek meg. A beadást követően a papír online is elérhető lehet, például az e-print archívum részeként http://www.arxiv.org (korábban xxx.lanl.gov). Az érdekelt felek az Interneten keresztül kommunikálnak a papír elkészítése során, illetve annak közzététele után, de az ilyen együttműködést korlátozza az a tény, hogy a dokumentumot soha nem írták meg, és ritkán olvasták fel, a Web natív HTML formátumát. Különösen tragikus, ebben a tekintetben, a HTML képtelen kifejezni matematikai jelölést.

Az Internet groupware ideális végrehajtása lehetővé tenné számunkra, hogy közös elektronikus terekben dolgozzunk, amelyek:

  • ad-hoc, a központi hatóság segítsége nélkül
  • elérhető ingyenes, univerzálisan elérhető szoftver
  • es tűzfalon belül és kívül egyaránt elérhetőek a kollégák számára
  • erősen titkosított
  • mögött egy gazdag, tranzakciós adattárolóval

Ezek a megosztott terek olyan alkalmazásokat támogatnának, amelyek:

  • folyékonyan integrálja a gazdag szövegeket, egyenleteket, vektorokat és raszterképeket, a hangot és a videót
  • szabványos alkatrészekből állnak
  • az adatok szokásos módon történő megjelenítése
  • együttműködési protokollok (eseményütemezés, vita, dokumentum-felülvizsgálat, projekttervezés) encapsule (encapsule collaborative protokollok)
  • segítsen az embereknek összpontosítani a figyelmet a “fontos” cucc

Senki sem vitatná ezeket az elveket. De hogy jutunk el innen oda, és mikor? Ez a jelentés számos olyan terméket, szolgáltatást, technológiát és technikát vesz figyelembe, amelyek együttesen mind rövid távú, mind hosszabb távú választ sugallnak ezekre a kérdésekre.

A jelentés négy részre oszlik:

  1. Rendezvény Koordináció. Amikor megbeszéléseket szervezünk, végül megegyezünk egy időben, egy helyen és egy csoport résztvevőben. De a protokoll nem csak a naptárak szinkronizálásáról szól. Ez magában foglalja a vitát és a tárgyalást is. A webalapú szolgáltatások segíthetnek mind az eseménykoordináció strukturált, mind félig strukturált szempontjainak kezelésében.
  2. Csoportos Megbeszélés. A levelezési listák, a csoport üzenetküldés domináns módja, problematikus. Szerencsére vannak olyan alternatívák, amelyek megkönnyíthetik a megosztott beszélgetési terek létrehozását, illetve hatékonyabbá tehetik a használatot.
  3. Hírek közvetítése és megfigyelése. A fizikai e-print archívum www.arxiv.org átalakította, ahogy a tudósok nyilvánosságra hozzák a saját munkájukat, és figyelemmel kísérik a kollégák munkáját. A webes tartalom szindikálásának új szabványa általánosíthatja és kiterjesztheti ezt a folyamatot.
  4. Tudományos Kiadás. A TeX és a LaTeX tudományos kiadást határoz meg a tudósok egy generációjának. De ezek a formátumok nem integrálódnak közvetlenül a megosztott terek az Interneten. Az XML egyetemes jelölőnyelv, valamint a szókincsek, mint például a MathML (a matematikai jelöléshez) és az SVG (a méretezhető vektorgrafikához) növekedése arra utal, hogy a Web még elérheti eredeti együttműködési célját.
1 Eseménykoordináció

Most már számos ingyenes (reklám által támogatott) webszolgáltatások, amelyek segíthetnek racionalizálni a kommunikációs erőfeszítést szükséges koordinálni egy eseményt. Ezek közé tartozik: 27

  • invites.yahoo.com
  • www.evite.com
  • www.timedance.com

Ezen szolgáltatások bármelyikének használatával létrehozhat egy “esemény objektumot” a webtérben, valamint megadhatja az eseményre meghívni kívánt személyek e-mail címét. (A feladat egyszerűsítése érdekében ezek a szolgáltatások számos közös címjegyzék-formátumot importálhatnak.) A szolgáltatás automatikusan mail meghívókat, amely beágyazása URL vezet vissza, hogy a megosztott tér, egy olyan környezetben, amely lehetővé teszi, hogy automatikus táblázatos RSVP vissza, hogy nem támogatja a csoportos megbeszélés (pl., üzenőfal) negotation ideje, helyszíne, napirendi.

Nézzük meg az egyik kifinomultabb implementációt, az időbeosztást, részletesebben. Ha én szervezek egy eseményt, és meg akarom kínálni a választás idejét, a protokoll így hangzik:

  • Javasolnék egy listát a lehetséges időpontokról a meghívottak listájára. Bár én mag a listát e-mail címek, én is úgy dönt, hogy átruházza a feladatot, hogy meghívja másokat. Ha egy meghívó így van beállítva, bárki adhat nevet a meghívóhoz – nagyon hasznos, ha meg akarom hívni az embereket, nem tudom az e-mail címüket, de gyanítom, hogy mások igen.
  • Az időbélyegzői szavazások ezekben az időkben. Minden ilyen lekérdezési üzenet tartalmaz egy egyedi kódolt URL, így, ha rákattint a szavazási oldalon az oldalon, tudja, hogy ki vagy.
  • Minden invitee díj minden javasolt alkalommal, mint “Nagy” vagy “Igy-Igy” vagy “Nem Jó.”
  • A tárgyalási szakaszban, a rendezvény web oldal mutatja az állapotát, mint “az emberek szavazni időkben,” — döntően — a vitafórum elérhető támogatás szabadkézi tárgyalás.
  • Amikor mindenki szavazott, TimeDance Figyelmeztet e-mailben, átadva egy URL egy olyan weboldalra, amelyen összevetette az eredményeket. Time slots amikor mindenki elérhető megjelenik, mint zöld fény. Bármely nyílás kiválasztható, hogy megjelenítse az adott nyíláshoz tartozó összes felhasználó beállításainak térképét.
  • TimeDance egy “legjobb” időt javasol, és arra kér, hogy válasszak (vagy egy másikat), és jelentsem be a csoportnak.
  • TimeDance rebroadcasts a most ütemezett meghívás, és megkezdi a RSVP fázis. Ismét minden üzenet egy egyéni URL tartalmaz, amely személyre szabott helyre vezet. Ha ez egy fizikai találkozó, ahelyett, hogy mondjuk egy teleconferece, látni fogja a helyét, és megtekintheti a térképet (ha a TimeDance képes volt, hogy keresse meg a címet). Az esemény Outlook, Netscape vagy más vCard-észlelő naptárhoz való hozzáadásához egy hivatkozást is talál. (a vCard a naptáradatok cseréjének szabványa. Lásd az Internetes Levelezési Konzorcium at http://www/pdi.org további információért.)
  • A RSVP, akkor bejelenti a tervek (“Részt”, “Nem részt”,”Nem biztos”). A vitafórum ismét rendelkezésre áll, hogy a meghívottak beszélgethessenek. Az egyik dolog, ami befolyásolja a döntését, hogy részt vesz (vagy nem), az a meghívottak listája, és azok szándékai. Ha az esemény szervezője azt mondta a TimeDance-nek, hogy tegye elérhetővé ezeket az információkat, akkor megteszi. A négy kategória mindegyikében megjelenik egy összefoglaló az emberek számáról: “Részt vesz”,”Nem vesz részt”, “Nem biztos”, és “Még nem válaszolt”. És látni fogja az egyes csoportokhoz tartozó nevek és címek listáját. Ez egy nagyon erős funkció, amely lehetővé teszi az esemény koordinátor (vagy bárki más), hogy kommunikálni minden ilyen dinamikusan fenntartott listák.
  • Az esemény weboldala (ami alapértelmezés szerint privát, de nyilvánosságra hozható) most nyomon követi az RSVP folyamatot. Figyeli, ki van minden kategóriában, és támogatja a csoportbeszélgetéseket.
  • Ha erre van konfigurálva, a TimeDance emlékezteti a nem válaszadókat, hogy válaszoljanak, és emlékezteti a megerősített résztvevőket, hogy vegyenek részt.

A TimeDance az Internet groupware 2000 egyik kiemelkedő példája. Itt vannak az okok, hogy ez így:

  • Szolgáltatásként működik.

Nincs szoftver telepíteni; a felhasználók egyszerűen könyvjelző az alkalmazás.

  • Alacsony aktiválási küszöb.

Az eseménykoordinátornak regisztrálnia kell a szolgáltatásban, de a regisztráció után nagyon kevés erőfeszítéssel új meghívót hozhat létre. A meghívottaknak nem is kell jelentkezniük, bárki, akit meghívtak, szavazhat, vitathat, vagy RSVP.

  • Használja, de nem visszaélés, email.

Az e-mail felhasználók által érzett fájdalom nagy része abból ered, hogy az üzenetküldési protokollok nem tekintik a személyes e-mailt elsőbbségi kommunikációs csatornának. TimeDance dicsérettel küld e-mailt szigorúan “kell tudni” alapon. A meghívottaknak e-mailt kell kapniuk, ha egy ideig RSVP, vagy amikor felkérik őket, hogy válaszoljanak, vagy ha a tervezett idő megváltozik. De nem akkor, ha valaki RSVP vagy ha üzenetet küld a táblának. Elég sok üzenetküldés történhet időben, de ez csak az esemény megosztott tér, ahová tartozik.

  • Egy praktikus, hatékony web/e-mail hibrid.

Az üzenetküldés olyan alapvető tevékenység, amelyet jog szerint olyan platformnak kell támogatnia, amely teljesen testreszabható, programozható, mint a webböngésző. A kérlelhetetlen e-mail infrastruktúra nem (még) olyan rugalmas. Így a mai internetes groupware gyakran igénybe kínos keveréke e-mail kommunikáció, valamint a web for application funkciók nem lehetséges (vagy mindenesetre, nem általánosan támogatott) az e-mail kliensek. Az időmérés a megfelelő egyensúlyba kerül. Arra számít, hogy a levelezőprogram automatikusan aktiválja (azaz kattinthatóvá teszi) az URL, amelyet küld Önnek, és intelligensen elég rövid ideig tartja az URL ahhoz, hogy elkerülje a vonaltörést, amely tönkreteszi ezt a hatást. De a csak szöveges olvasó, mint például a pine, akkor könnyen elfog az URL, majd át egy böngésző.

  • Automatizálja a legfontosabb adminisztratív feladatokat.

Közvélemény-kutatás a nyitott idő RSVP, rendezi jeleztek vissza, beállítása üzenőfal ráadásul több levelezési listák tevékenységek egyél több, a magasan fizetett tudós, mint ő, vagy ő akar beismerni. Azon a használati szinten, TimeDance a határidő megfelelő — mondjuk, a több mint két vagy három ember részvételével, kevesebb, mint ötven vagy száz — automatizálja ezeket a dolgokat meglehetősen szépen.

  • Vajon “kontextus összeszerelés”

Amikor a hagyományos e-mail az eseménykoordináció médiuma, mindenkinek nyomon kell követnie mindent, ami az eseményhez kapcsolódik — magát a meghívót, a kapcsolódó dokumentumokat, mint a térképek, vitaüzenetek. Az e-mail szűrés használható az üzenetforgalom átirányítására egy kijelölt Bejövő mappába, de nem mindenki tud, vagy fog menni a baj. Ha az e-mail nincs archiválva és nem látható a weben, bárki, aki később csatlakozik a listához, lemarad a korai beszélgetésről.

Van egy sürgős (ha nagyrészt unarticulated) szükség a szoftver, hogy segítsen összegyűjteni ezeket a bit információkat egy értelmes kontextusba. Ha nincs ilyen szoftver, akkor a saját kárunkon alkalmazzuk az együttműködési protokollokat. Mert a számítógépek nem tudom események olyan események, a helyi közgyűlés — nyomon követését, ki válaszolt, külön rendezvénnyel kapcsolatos vita, a többi beszélgetés, emlékezés, ahol a meghívó, valamint a térkép — a fejünket. Ehhez idő és erőfeszítés szükséges, nem csak a koordinátor, hanem az összes érintett fél részéről. Egy olyan szolgáltatás, mint a TimeDance megmutatja, hogyan kell működnie a dolgoknak. Mivel egy együttműködési protokollt testesít meg, értelmezhető kontextusba helyezi azt, ami egyébként egy eltérő dokumentum és üzenetkészlet lenne.

2 Csoportos Megbeszélés

A levelezési listák a csoportbeszélgetések de facto szabványai, írásos formában. Az előnyök egyértelműek. Könnyű létrehozni egy levelezési listát, különösen most, hogy a Web alapú szolgáltatások, mint például http://www.egroups.com/ (ingyenes, reklám támogatott) és http://www.lyris.net/ (kereskedelmi, de olcsó) tudja kezelni az összes szerver adminisztráció az Ön számára – beleértve a list management, digest szállítás, valamint kereshető web archiválás. Természetesen bárki csatlakozhat egy levelezési listához, bármilyen internetes levelezőprogram segítségével.

De a levelezési listák nem a legjobb, vagy csak megosztott szóközök a csoportos beszélgetéshez. Íme néhány probléma:

  • Levelezési listák kínos web / e-mail hibridek

Az e-maileket kézbesítés céljából terjesztik, de a navigáció és a keresés céljából (web archívumban) újraértékelik. Tehát nem világos, hogy pontosan mi is az a megosztott terület, amit a tagok foglalnak el. A tagok egyéni postaládáinak gyűjteménye, vagy a webarchívum, vagy mindkettő? Egyes webes archívumok teljes körű részvételt tesznek lehetővé, mások csak olvasást és keresést támogatnak.

  • A levelezési listák nem könnyen biztonságosak

A PGP vagy S/MIME használatával az e-mailek végpontról végpontra történő titkosítása széles körben elérhető. A levéltitkosítás azonban nem teljesen érthető, nem széles körben használják az interperszonális levelezéshez, logisztikailag lehetetlen a levelezési listák számára, amelyeket különböző levelezőprogramok, illetve (archív formában) böngészők használnak. És mivel a Levelezőlista által létrehozott megosztott terület sok merevlemezre terjed, eleve nehéz biztosítani.

  • E-mail nem egy gazdag médium a diskurzus

A rögzített Vonalú ASCII e-mail üzenet korlátain belül van egy nagyon erős eszköz: az URL. A legtöbb levelezőprogram automatikusan végrehajthatóvá teszi az URL-eket. Ez a képesség, hogy idézni gazdag web-alapú források pusztán elnevezése őket radikálisan kiterjesztette a kifejező erejét e-mail. De e-mail vita csak utal ilyen dokumentumokat. Általában nem hozza létre őket.

  • A levelezési listák nem tartalmaznak hatékonyan réteginformációkat

Az újság és a lap szerkesztői évekig kántálták a mantra “fejeket, fedélzeteket és vezetőket.” Azt feltételezik, hogy nobobynak van ideje mindent elolvasni, és hogy minden publikált tételt rétegekben kell csomagolni. A főcím a történetet néhány szóban mondja el; a fedélzet (felirat) egy mondatban; a vezető (absztrakt) egy bekezdésben. Egyes kontextusokban lehet, hogy csak elég hely van a szalagcím megjelenítéséhez; más kontextusokban az összes elem megjelenhet. A rétegzett építészet a történet része. A megjelenítők ezután kiválaszthatják és elrendezhetik ezeket az összetevőket, hogy maximalizálhassák az erőforrások szűkösségét: az olvasó figyelmét.

E-mail, mint egy kiadói médium, nem katasztrofálisan megengedheti magának ezt a fajta rétegezés. A beérkező levelek vagy e-mailek archívumának beolvasásakor csak az üzenet címe-azaz a tárgy: fejléc-írja le az üzenetet, valamint egy nyom, hogy érdemes-e több időt és erőfeszítést fektetni az olvasásba. Sajnos, a szokás és az e-mail menettel kapcsolatos régóta fennálló probléma miatt a címeket szinte mindig csak a menetvágás jelzésére használják. Az ebből eredő kaszkád Re: szindróma, amely megfosztja címeit leíró hatalom, látható mindenhol-a saját postaládájában, valamint számtalan levelezési listák. Itt például egy tipikus Levelezőlista pillanatkép, a Zope fejlesztői listából:

Abra 1: a Zope-Dev lista pillanatképe 

Mi a baj ezzel a képpel? Ellenpéldával tudok a legjobban illusztrálni. A következő módon szeretném megtekinteni ezt a szálat:

Abra 2: Idealizált pillanatfelvétel a Zope-Dev listáról 

ZServer speed enhancement (I hope) - Andy Dustman
    How much faster is it? - Brian Lloyd
    Honestly, I don't know. More improvements coming... - Andy Dustman
      Try apache-bench - Hannu Krosing
  New version now available - Andy Dustman
    That one's broken - Ben Leslie
      Oops, you're right, sorry, fix coming... - Andy Dustman
        Any performance tests yet? - Hannu Krosing

Fényében Abra 2 az Abra 1 katasztrofális információs kijelző. A szálszerkezet leképezése gyakorlatilag használhatatlan leíró üzenetcímek hiányában. Claude Shannon úgy definiálta az információt, mint azt, amit nem tud.hogy a következő üzenet mennyire meglepi Önt egy üzenetsorozatban. Az Abrán 1 a “Szerver speed enhancement (remélem)” ismétlése egyáltalán nem meglepő. Az üzenet címeinek ez a sorozata szó szerint nem tartalmaz információt, mégis ez az egyetlen elérhető felület a mögöttes tartalomhoz.

Az Abra 1 az Abra 2 közötti különbség nem is lehetne drámaibb. Abrán 2 kattinthat az egyes üzenetekre, de nem kell kattintania, hogy elnyelje ennek a szálnak az értelmét. Az üzenet címei maguk adják át az információt, ők mesélnek egy történetet.

Ez lehet, hogy úgy tűnik, mint egy pedáns Pont, de ha valaha is töltött időt, hogy próbálja ki információt a levelezési listák (és ki nem?), láthatjuk, hogy a kaszkádos Re: szindróma felelős a katasztrofális információvesztésért és az eredménytelenségért. A levelezési listák nem igazán ellenőrizhetők. Csak azokat a listákat érdemes elolvasni, amelyeken a forgalom elég könnyű (és értékes) ahhoz, hogy tartós figyelmet kapjon. Az olyan emésztések, amelyek csak címeket szállítanak, csak korlátozottan használhatók, amikor a legtöbb címnek nincs jelentése. Hasonlóképpen a levelezési listák webes archívumai, mivel az indexelt nézetek (és a keresési eredmények) elsősorban a redundáns címek listája.

Szeretnénk, ha a postaládáink úgy néznének ki, mint Abra 2. De nyilvánvaló, hogy nem vagyunk hajlamosak úgy gondolkodni és viselkedni, mint kiadók és szerkesztők. Erre a problémára nincs egyszerű megoldás. A válasz egy része szociokulturális. Fajként nagyon kevés tapasztalatunk van abban, hogy az internetes csoportos üzenetküldés által lehetővé tett megosztott terek fajtáit használjuk. Most fedezzük fel, hogy az információs autópálya verbális szennyezése olyan kellemetlen, mint az alom az igazi autópályán. Ahogy a középiskolás diákokhoz vezető út szabályait is elmagyarázzuk, úgy dönthetünk, hogy ezeknek az embereknek is el kell magyaráznunk, hogyan kommunikáljanak tömören és hatékonyan az Interneten.

A válasz másik része a technikai. Az üzenetküldő szoftverünknek meg kell értenie, hogy a hasznos megosztott helyek megkövetelnek bizonyos típusú viselkedést, és meg kell találnia a módját annak, hogy ösztönözze és támogassa ezeket a viselkedéseket.

  • A levelezési listák gyakran nem tudnak megfelelően üzeneteket fűzni

E-mail menetes szervez üzeneteket témánként. Két üzenet fejlécének egyike — Hivatkozások: (e-mailhez és hírcsoportokhoz) vagy Válasz:: (e-mailhez) — egy üzenetet egy vagy több előzményhez kapcsolódik. A legtöbb e-mail program most egy vagy mindkét fejlécet bocsát ki, amikor válaszol egy üzenetre, és ezeket a fejléceket használhatja a kapcsolódó üzenetek menetes megjelenítésére. De ez nem volt mindig igaz, és még mindig nem néhány e-mail programok. Tehát, míg elvben nincs szükség a témára támaszkodni: egy üzenetet a témához kapcsolni, a gyakorlatban a szokás szinte egyetemes. Mivel a legfontosabb témának két ellentmondásos felhasználása van: fejléc-üzenet engedélyezése, illetve üzenet a környező kontextushoz való kapcsolása-a levelezőprogramok és a levelező archivátorok gyakran nem tudják megfelelően megjeleníteni a szálakat. És minden esetben, ahogy láttuk, a menetes kijelzők jellemzően közvetítik a szerkezetet, de nem sokat jelentenek.

2.1 Levelezési listák alternatívái

2.1.1 NNTP hírcsoportok

Idén a Usenet évfordulóját 20 ünnepli. Ez a nagyapja minden groupware rendszerek: a planetáris vitahálózat, amely támogatja több tízezer virtuális közösségek. Legjobb tudásuk szerint ezek a közös terek lehetővé teszik a hasonló gondolkodású egyének csoportjai számára, hogy meglehetősen hatékonyan működjenek együtt. A legrosszabbkor, tele vannak löncshússal, mocsokkal és ostobaságokkal. Ez a leépülés megmérgezi az Usenet fogalmát, és ami még rosszabb, megakadályozza, hogy teljesen megértsük és kihasználjunk néhány igazán hasznos, jól megalapozott, együttműködő eszközt, az NNTP (Net News Transfer Protocol) szervereket és ügyfeleket.

Lehet, és lehet, hogy újra kellene feltalálnunk az Usenet. Még akkor is, ha jól működik-például sok kiváló minőségű moderált Usenet csoportok-a replikációs rendszer lett szörnyen hatékonytalan. Minden adott Usenet csomópont sokkal több üzenetet fogad és dolgoz fel, mint bárki, aki a csomóponthoz csatlakozik, valaha is el fogja olvasni. Miért? Amikor a Usenet felnőtt, nem volt olyan dolog, hogy majdnem univerzális, valós idejű adatátviteli hálózat. A replikáció volt az egyetlen módja annak, hogy üzeneteket terjesszünk világszerte különböző és intermittáló hálózatokon keresztül. Ma newsreaders azonnal csatlakozni számos különböző hírkiszolgálók, csakúgy, mint a böngészők csatlakozni számos különböző weboldalak.

Képzeljünk el egy alternatív használatot. A virtuális közösségek száma és a csomópontok száma megegyezik. De minden csomópont felelős csak egy vagy több megosztott terek, nem az összes. (Az NNTP replikációja még mindig tükrözheti a csomópontokat a világ néhány pontján, hogy javítsa a helyi hozzáférést, de a replikáció tárolási és feldolgozási költségei jelentősen csökkennek.) Ha minden csomópont egyre kevesebb üzenetet dolgoz fel, a hangsúly a mennyiségről a minőségre válthat. Íme néhány a következmények:

  • Az üzeneteknek soha nem kell lejárniuk, így minden hírcsoport évekre emlékszik, nem pedig napokra.
  • Mivel az üzenetek soha nem járnak le, állandó URL névteret határoznak meg.
  • Egy szerkesztő-az a személy, aki ma fenntartja a newsgroup GYIK fájlját-létrehozhat nézeteket erről az állandó névtérről. Ezek a nézetek kijelölhetik, összegezhetik, illetve megjegyzhetik az iránypont-hozzájárulásokat.
  • A keresés optimalizálható egy adott hírcsoport jellemzőire, valamint a hozzá tartozó tudástartományra.

Függetlenül attól, hogy az Usenet átszervezi ezeket a vonalakat, döntő fontosságú, hogy elkülönítsük a megosztott vitatér gondolatát a megvalósítástól, mint az Usenet. Az Usenet együttműködési modellje-és meglévő, bizonyított eszközei és technológiái-átcsoportosítható nyilvános oldalakon, extraneteken és intraneteken. NNTP conferencing lehet egy jobb fajta levelezési lista, amely támogatja a fajta együttműködés, hogy a Web eddig nem szállított.

Az NNTP szerverek, nevezetesen a standard UNIX INND (InterNet News Daemon) szabadon elérhetők. Az ilyen szerverek széles körben úgy gondolják, hogy szükség van a varázslás, de valójában az egyetlen nehéz része, hogy tartsa a hírmagvak fut. És erre semmi szükség. Nem kell replikálódnia az Usenet-vel ahhoz, hogy hozzáférjen hozzá; olyan szolgáltatások, mint például http://www.dejanews.com/usenet/ és http://www.remarq.com/ szolgálja fel a Usenet tartalmat és támogatja a Usenet interakció. Helyi hírszolgálatot indítunk, hogy támogassuk a nem Usenet Levelezőlista-szerű megbeszéléseket, ami nagyon egyszerűnek tűnik. A news spool lehet indexelni, a keresés, csakúgy, mint bármely gyűjteménye weboldalak vagy e-mailek. A hírcsoportok jelszóval védettek lehetnek, ahogy a webes archívumok is. Egyszerű biztonságos csatornákat létrehozni a hírkiszolgáló és a hírolvasók lakossága között folyó forgalom számára.

A Windows NT rendszert futtató webhelyek esetében az NNTP Service az NT Option Pack alulértékelt gem. Nagyon könnyű használni, és nagyon praktikus. Kevés idő vagy szakértelem Szükséges egy biztonságos kapcsolatokat elfogadó, fulltext keresést támogató vitaszerver beállításához, amely több adatvédelmi zónára osztható, és integrálható a Windows NT felhasználói könyvtárába.

A hírolvasó-alapú vita előnyei

Az NNTP szerverekhez hasonlóan az NNTP newsreaders is alulértékelt erőforrásokat kap az együttműködéshez. A legtöbb ember tudja, hogy a Microsoft és a Netscape hírolvasók egyszerű szöveges üzeneteket küldhetnek a hírcsoportoknak, illetve bináris fájlokat csatolhatnak. De a newsreaders kínál néhány más, kevésbé széles körben elismert együttműködési előnyöket vis-a-vis levelezési listák:

  • Egy üzenőbázis, egy interfész.

A levelezési listák szét vannak osztva, az interfész pedig multi-modális. Ennek egyik következménye, hogy egy új résztvevő, aki egy webarchívumba megy, hogy átnézze az előzetes megbeszéléseket, nem csatlakozhat ehhez az előzetes megbeszéléshez. Egy hírcsoport esetében a vita bármikor teljes mértékben elérhető bárki számára, ugyanazt a mechanizmust használva az olvasáshoz és az íráshoz.

  • Hatékony menetvágás.

A hírcsoportok a menetes nézeteket hatékonyabban kezelik, mint a levelezőlistákat, mert a hírolvasók következetesebbek A hivatkozások: fejléc használatában. Ez azonban nem oldja meg automatikusan a cascading Re: probléma.” Mint archivált néző, levelezési listák, hírcsoportok vagy hasznosan leolvasható, csak akkor, ha a résztvevők megértsék, hasznosítására, az elv leíró üzenetet feliratozás. Amikor a felhasználók annyira hajlanak, egy NNTP vitaszerver jobban támogatja a technikát, mint egy levelezési lista általában.

  • Gazdag üzenetek.

Mind a Netscape, a Microsoft, a WYSIWYG módon, komponálja meg a HTML, amely táblázatok, beágyazott képek (amely lehet húzni csökkent a helyére), hivatkozások, betűtípusok, színek. Nem lehet ezeket a dolgokat a Usenet postings, mert sok ember nem fut HTML-tudatában posta/hírek ügyfelek. De a gazdag üzenetküldés megfelelő lehet olyan együttműködési környezetben, ahol ezeket az eszközöket általánosan alkalmazzák.

Ez egy indokolatlan használata HTML? A sima vonalorientált ASCII szöveg elegendő a tudományos együttműködéshez? Hagyományosan ez volt, és az első generációs HTML üzenetek bevallottan majdnem olyan problematikus, mint hasznos. Sok tudományos munkatársak ma, TeX mellékletek egy jó-elég megoldás. De a mai HTML e-mail nem a végjáték a rich-text messaging. Az XML szókincsek, például a MathML és az SVG (lásd a 4 szakaszt) egyre nagyobb teret nyernek. Kevesen tagadnák a mindenütt jelen lévő üzenetküldő eszközök előnyeit, amelyek natívan értik a matematikai egyenleteket, illusztrációkat, valamint a gazdag szöveget. Amint látni fogjuk, az ilyen eszközök támogatásához szükséges infrastruktúra kialakulóban van, és ésszerű elvárni, hogy néhány éven belül használni tudjuk ezeket az eszközöket.

  • Biztonságos kommunikáció.

Az emberek gyakran aggódnak a titkosítási szint miatt, amely védi a hitelkártya-számukat, amikor egy e-kereskedelmi weboldalról rendelnek. Ugyanazok az emberek ritkán aggódnak amiatt, hogy titkosítatlan bizalmas kommunikációt küldenek egy egész SMTP-útválasztón keresztül. Bizalmas megbeszéléseket kellene folytatnunk biztonságos közös terekben, és a megfelelően konfigurált NNTP hírcsoportoknak meg kell felelniük ennek a követelménynek.

2.1.2 QuickTopic

Bármennyire is hasznosak lehetnek az NNTP-megbeszélések, nem felelnek meg az ideális együttműködési megoldás egyik követelményének. A legtöbb ember nem alkothat NNTP vitatereket menet közben, egy központi hatóság segítsége nélkül. Innovatív szolgáltatás, http://www.QuickTopic.com/ (korábban www.TakeItOffline.com), foglalkozik pontosan ezt a problémát. Ez egy posta/hírekhibrid, amely létrehoz “azonnali vita terek” minden összpontosított egyetlen téma

A QuickTopic használatához látogassa meg az oldalt, nevezze meg, írja le a vitatémát, majd adja meg e-mail címét. Az oldal létrehoz egy beszélgetési helyet, majd e-mailben egy URL-t küld rá. Ahhoz, hogy másokat is bevonjon a vitába, továbbítsa nekik ezt az üzenetet (vagy csak az URL-t). A témakörök menetvágás nélkül lineáris stílusban jelennek meg, de létrehozhat egy új témát, és összekapcsolhatja egy meglévő témával, hogy elágazó hatást hozzon létre.

Mennyire bizalmasak ezek a beszélgetések? A dokumentáció őszintén kifejti:

A téma a Take It Offline épp olyan privát, mint a webcíme-nem több, nem kevesebb. Ezt a címet rendkívül nehéz kitalálni. Ez egy véletlenszerűen generált alfanumerikus karaktersorozat.

Ez az URL ez ajelszó megoldás jó számos alkalmi használatra. Szigorúbb biztonsági protokollok természetesen lehetséges. Könnyen titkosítható lenne a QuickTopic webkomponense, bár sokkal nehezebb titkosítani az e-mail komponens, miközben megőrzi a spontaneitást, amely kulcsfontosságú ereje a rendszer.

QuickTopic úgy tervezték, hogy ne cserélje ki a levelezési listát, hanem, hogy növelje azt. A levelezési listák, hírcsoportok és webes fórumok a legalkalmasabbak a hosszú távú együttműködésre. Ezek a megoldások általában túl nehezek és túl statikus, az ad hoc, rövid életű interakciókhoz képest, amelyek a valódi együttműködésünk nagy részét jellemzik. Ezekben a helyzetekben mindig használja e-mail, annak ellenére, hogy a korlátozások, mert könnyen kéz. Mint az egy témájú hirdetőtábla, amely egy időeltolódás eseményhez kapcsolódik, a TimeDance is ad QuickTopic, könnyű és eldobható, de fókuszáltabb, központosabb és könnyebben hozzáférhető, mint egy levelezési lista.

2.1.3 Roundup és “kíváncsi listák”

Ka-Ping Yee ‘s Roundup (http://software-carpentry.codesourcery.com/entries/track/Roundup/Roundup.html), egy bejegyzés a Szoftver Asztalos projekt nyomkövető kategóriában, javasolja a mechanizmus egy témájú, ad-hoc vita úgynevezett “kíváncsi lista”, amely így működik:

  • A Roundup-nak küldött e-mailek mindig új elemeket nyújtanak Roundup. A “Tárgy:” mező az új elem leírása lesz. Az üzenet az új elem levelező orsójába kerül, majd az összes résztvevő listájára kerül, így mindenki tudja, hogy új elem került hozzáadásra. Az új tétel kotnyeles listája kezdetben tartalmazza az alámerülőt. 
  • A Roundup által küldött összes e-mail üzenetben a “Válasz:” mező a Roundup címére van állítva, az elem számát pedig a “Tárgy:” mezőbe kell beírni. Így a Roundup minden válaszát megkapja az első bejelentésre és a későbbi menetekre. A Roundup minden bejövő üzenet “Tárgy:” mezőjében megjegyzi az elem számát, majd a megfelelő oszlophoz csatolja az üzenetet. 
  • Az elemszámmal megjelölt bejövő e-maileket a rendszer átmásolja az elem kotnyeles listáján szereplő összes személynek, valamint a “From:”, “To:” vagy “Cc:” mezőket automatikusan hozzáadja a kíváncsi listához. Amikor egy felhasználó szerkeszti egy elem tulajdonságait a webes felületen, akkor azok is hozzá a kíváncsi lista. 

A hatás olyan, mint minden elem saját kis levelezési lista, kivéve, hogy soha senkinek nem kell aggódnia feliratkozás semmit. A kérdés iránti érdeklődés elégséges, és ha valaki újat szeretne bevonni a beszélgetésbe, csak Cc: üzenetet kell küldenie nekik. Kiderült, hogy soha senkinek nem kell aggódnia a leiratkozás, sem: a kíváncsi listák olyan konkrét hatókörben, hogy a beszélgetés hajlamos elhaladni magától, ha a kérdés megoldódott, vagy az emberek már nem találják eléggé fontosnak. 

Sok kis, speciális levelezési listák használata sokkal hatékonyabb kommunikációt eredményez, mint egy nagy lista. A feliratkozás és a leiratkozás erőfeszítésének elvétele e listák számára az olcsó és eldobható lét “érzését” adja. 

Az egyes kérdésekhez csatolt levelezőcsomag átlátható rögzítése szintén szép tudástárat biztosít az idő múlásával. 

Ez a stratégia azért erőteljes, mert kihasználja és értékesebbé teszi a meglévő eszközöket és szokásokat. Üzenetküldés, ebben a rendszerben, történik egy jól meghatározott környezetben – egy adott projekt, egy adott probléma kapcsolódó projekt. Mint a TimeDance, a Roundup is nyomon akarja követni a kontextust, hogy a felhasználóknak ne kelljen.

2.1.4 WikiWiki eszközök

A menetes üzenetküldés nem az egyetlen modell az online beszélgetéshez. A népszerű alternatíva a WikiWiki (Hawaii a “gyors”), egy freeform együttműködési eszköz, amely inkább hypertextual struktúra a szálszerkezet. Az eredeti WikiWiki, az együttműködés a programozók között, hogy még mindig folyamatban van a Portland Pattery (http://www.c2.com/cgi/wiki?WelcomeVisitors) egy radikális kísérlet: egy gyűjtemény online dokumentumok, amelyek mindig szerkeszthető mindenki.

A szerkesztési környezet WikiWiki két fő jellemzője van:

  • Az új dokumentumok automatikusan létrejönnek. 

Míg a Levelezőlista-üzenetek hivatkozhatnak meglévő Webtartalomra (hivatkozással URL-ekre), általában nem hozhatnak létre új Web tartalmat. A Wiki környezetben, speciálisan megírt WikiNames-amelyek csak vegyes-eset, run-together kifejezések-támogatja az automatikus hypertext szerző. Ha beírom a “Bibliográfiai Hivatkozások” kifejezést egy Wiki oldalon, akkor először így jelenik meg:

Bibliográfos megoldásokat?
Most a kifejezés egy meghívó, hogy hozzon létre egy új dokumentumot, hogy a név. Bárki létrehozhatja ezt a dokumentumot, ha rákattint a csatolt kérdőjel gombra, majd beírja valamit a szerkesztőbe. Miután ez megtörtént, a “BibliographicalReferences” kifejezés jelenik meg, minden oldal tartozó Wiki gyűjtemény, mint így:

BibliographicalReferences

Az e-mailekben található URL-ekhez hasonlóan ezek a Wikinamek is automatikusan kattintható hivatkozásként jelennek meg a weboldalakon. De itt, a folyamat létrehozásának a dokumentum által címzett link automatizált.

  • HTML-összetétel egyszerűsített. 

Mit tud beírni az újonnan létrehozott Wiki oldalra? Íme néhány példa:

Abra 3: Wiki formázás

te típus                                            Wiki renderelők

1
  *list item 1

    *indented list item a

    *indented list item b

  *list item 2
  • tétel 1
    • indexált tétel a
    • indexált tétel b
  •  tétel 2
2
This non-indented text renders in a proportional
font. Now use indentation to introduce a monospaced
code example:



  sillyFunction(arg1,arg2)


      { return 0; }

Back to normal font.

Ez a nem indexelt szöveg arányos betűtípust képez. Most használja a behúzást, hogy bemutassa a monospaced kód példáját:

  sillyFunction(arg1,arg2)
    { return 0; }

Vissza a normál betűtípushoz.

A sororientált szövegszerkesztőbe (például a böngésző <TEXTAREA> widget-jébe) könnyen beírható konstrukciók automatikusan felismerésre kerülnek, majd megfelelő HTML-jelöléssé alakulnak.

A wiki nem igazán oldja meg a jelölést, csak leegyszerűsíti. A fenti első példában a listák szabálya egy lap és egy csillag beírása egy első szintű elemhez, két lap plusz egy csillag egy második szintű elemhez, stb. A második példában a vezető szóköz azt mondja a formatternek, hogy a szöveg helyett (arányos betűtípus, bekezdésorientált) renderelje a kódot (monospaced betűtípus, vonalorientált).

Mennyire fontos ez az egyszerűsített árrés? Hosszú távon, akkor valószínűleg felváltotta a WYSIWYGS zerszámok. Eközben sok ember úgy tűnik, hogy hasznos.

2.1.5 Wiki klónok

Az eredeti Wiki egy sor derivatívát szült. Például, ha Zope-oldalt futtat, telepítheti a Zwikit, amely lehetővé teszi a Zope számára, hogy egy vagy több Wiki webs-t tároljon. Egy másik változat, az úgynevezett TWiki, foglalkozik az egyik aggodalom a klasszikus Wiki, ami az, hogy az egalitárius “minden oldal szerkesztése” filozófia nem hagy változás log. TWiki tartalmaz erőteljes felülvizsgálati támogatást. Minden változás nyomot hagy maga után, és ezeket könnyen és hatékonyan követheti.

2.2 A csoportos üzenetküldési lehetőségek áttekintése

A levelezési listák nem fognak, és nem is kellene, hogy elmenjenek. Fontos célt szolgálnak. De a régi mondás fontos itt: ha az egyetlen eszköz van egy kalapács, minden probléma kezd látszani, mint egy köröm. Sok együttműködési mód esetén a hagyományos levelezési lista nem a megfelelő eszköz. Melyik alternatíva a legjobb? Ez érzékenyen függ a változók kombinációjától. A hírcsoportok, a Wikikik és más alternatívák műszaki jellemzői befolyásolják az eredményt, de az együttműködést végző csoportok dinamikája is. Néhány csoport a wikit érthetetlennek találja; mások természetesnek veszik. Nincs (még) egyetlen kényszerítő stratégia a következő generációs csoportos üzenetek az Interneten. De vannak lehetőségek, amelyek a csoportos üzenetküldést-bizonyos csoportok számára, bizonyos célokból-eredményesebb és hasznosabb gyakorlattá teszik.

3 Műsorszórás és Monitoring Hírek

Az e-print archívum www.arxiv.org drámaian megváltoztatta a fizikusok publikálásának és nyomon követésének módját, az irodalmat az érdeklődési körükben. Más tudományos közösségek úgy tekintenek az archívumra, mint egy merész kísérletre, amely valószínűleg befolyásolja a saját gyakorlatukat. Eközben, ahogy az archívum továbbra is növekszik a lineáris módon, fizikusok kezdenek szembenézni néhány azonos információ-túlterhelés problémák, amelyek jellemző a Web általában. Egy közelmúltbeli kedden 36 új tanulmány volt a fizika archívum 12 részlegében, az asztrofizikában. Az asztrofizikusok olvashatnak napi 36 újságot? Meg kellene próbálniuk? Nyilvánvalóan nem. A fizikai archívum egyik felhasználója átvizsgálja a listát, rangsorolja a téma iránti érdeklődés, a szerzők ismerete alapján, szelektíven olvas, és talán továbbítja az érdekes elemeket a kollégáknak.

Minden webes felhasználó naponta részt vesz ebben a folyamatban az információ finomítása. Sokan megosztják az eredményeket-azaz, URL-ek jegyzeteket-formájában FYI (“For Your Information”) e-mailek. Néhányan a személyes “linkek” oldalakon is megosztják eredményeiket. És néhány alkalmaz egy új taktikát, a webloggingot. A weblog valójában csak egy kiegészítő link oldal, jellemzően egy napi Web formájában, amely a személyes és/vagy szakmai érdekek szerint szűri és reagál a webes információáramlásra.

A jelenlegi weblog őrület minden valószínűség szerint egy múló hóbort. Ha meglátogatja a Blogger (http://www.blogger.com), a portál, hogy az aggregátumok több mint 1000 blogok, megállapítható, hogy ez a kommunikációs forma már a sorsra jutott, amik a Usenet. Egy “blogger” (rövidítése “weblogger” ) a közelmúltban panaszkodott:

Volt egyszer egy remény, hogy a weblog egy erős eszköz lesz, hogy kinyúljon és összekapcsolódjon a világgal. Ehelyett az önelégültség és az önteltség erőteljes eszközévé vált.

De a mögöttes weblogging mozgalom két technológiai trendek — RSS kiemelt syndication nyomógomb Web publishing … halandzsázik jobb módja, hogy nyilvánosságra, monitor, a tevékenységek szakmai csoportok.

3.1 RSS fő szindikáció

Az RSS (Rich Site Summary) egy XML szókincs a megjegyzett hivatkozások kifejezésére. 1999-ben debütált, mint a my.netscape.com, egy szolgáltatás, amely összesíti a hírek “csatornák”, amelyek “adás” a felhasználók. Korábban, 1995-ben, a PointCast hálózat (most megszűnt) úttörője volt ennek az ötletnek. De a PointCast csatorna közzététele összetett folyamat volt. Ennek eredményeként hírhálózatát elsősorban a meglévő kiadói szervezetek használták ki, de végül kudarcot vallottak.

Netscape em radikálisan egyszerűbbé tette a folyamatot. Bárki közzétehet egy csatornát egy egyszerű XML-fájl webkiszolgálóra történő elküldésével, illetve a szolgáltatással történő regisztrálásával. A szolgáltatás felhasználói ezután személyre szabhatják a saját Netscape kezdőlapjaikat a rendelkezésre álló csatornákból választva. Íme, hogy nézhet ki a kezdőlap:

Abra 4: Csatornák RSS  ellenőrzése a My Netscape 

A középső oszlop a főbb hírkiadók csatornáit jeleníti meg. A bal és a jobb oldali oszlopok kisebb kiadók, projektcsoportok, sőt magánszemélyek által működtetett butikcsatornákat jelenítenek meg. Ebben a példában ezek a csatornák a saját érdekeimet tükrözik: a szoftvereket és a hálózatépítést. Jelenleg még kevés csatorna szentelt tudományos témák, de az ilyen csatornák könnyen, minden bizonnyal, és valószínűleg kialakul.

Ha az RSS csatornák csak az én Netscape emen jelennének meg, a mechanizmus korlátozott értékű lenne. De többről van szó. Az RSS bevette a standardot. Sok oldal RSS tartalmat szindikál, XML formátumú csatornák beszerzésével, html-ként. A Netscape-en kívül számos olyan oldal található, ahol az összesített RSS-hírcsatornák, nevezetesen a UserLand Software Az én UserLand (http://my.userland.com) and O’Reilly and Associates Meerkat (http://meerkat.oreillynet.com).

UserLand igazgatója, Dave Winer, két kalapot visel. Mint újságíró, ő már évek óta közzétett technológiai hírek formájában egy e-mail hírlevél, valamint egy kapcsolódó honlap, Scripting News (http://www.scripting.com). 1997-ben a Winer elkezdte kínál Scripting News egy XML formátumban alkalmas konzorciális. Az ötlet az volt, hogy, mivel a rendszeres, kiszámítható formátum a főcím is, más oldalakon akarta, hogy készítsen egy Scripting News feed könnyen szindikátus a tartalom — scoop fel az XML, újraküldési, mint a HTML szabott saját stílusok bemutatása.

Szoftverfejlesztőként a Winer kifejlesztette a termékét, az úgynevezett Frontier-t egy Macintosh parancsfájlnyelvből egy több platformos (Windows/Mac-alapú) internetes kiadói és tartalomkezelő rendszerré, Manila néven. Többek között csatornaíró eszköz. A Manila automatikusan elérhetővé teheti az általa kezelt tartalmat RSS formátumban szindikáláshoz.

Az O ‘Reilly Network Szurikátája egy “nyílt vezetékes szolgáltatás”, amely bemutatja az RSS szindikáció kialakulóban lévő tulajdonságait. Szurikáta órák csatornák felsorolt két RSS nyilvántartások-egy Felhasználói, egy xmlTree (http://www.xmltree.com). Az unió e két nyilvántartások (amelyek részben átfedő, részben eltérő), Szurikáta végez kiválasztása. Csak azokat a “technology/computer/geek” csatornákat választja, amelyek fontosak az O ‘ Reilly hálózat közönségének. Ezután kategorizálja ezeket a csatornákat, hogy egy Szurikáta-felhasználó egyetlen választhasson-mondjuk Python -, hogy a szalagcímeket és a maszkokat fél tucat Python kapcsolatos csatornáról megtekinthesse.

A színfalak mögött az O’Reilly Network szerkesztői és írói, ami maga is egy információs oldal szoftverfejlesztőknek és Internet technológusoknak, szurikátával követik az egyéni ritmusaikat. Érdekes elemeket választanak ki, további analízist adnak hozzá, majd a webhely eredeti tartalmával együtt újra közzéteszik azokat. Ezzel párhuzamosan fenntartják a Manila weblogs-ot, ahol újságíróként kevésbé formális, személyesebb, összefoglalóbb és elemzéseket tudnak nyújtani. Ezek a weblogok, hála Manila automatikus szindikációjának, visszakerülnek az RSS vezetékre. Például Edd Dumbill weblogja (http://weblogs.oreillynet.com/edd/).

Mindez egy újfajta információhoz vezet, amelyet az RSS-szerzők, az RSS-tartalmakat szindikátusi webhelyek, valamint az RSS-tartalmakat tömörítő, válogató, finomító és publikáló szolgáltatások tartalmaznak. A “technológia / számítógép / stréber” tér, amelyet a UserLand és a Szurikáta-félék foglalnak el, a hírek publikációja és asszimilációja radikálisan leegyszerűsített és felgyorsult. A hírek ebben a világban a szokásosnál szélesebb jelentéssel bírnak. Bármi, ami hivatkozhat egy URL-re, az fair játék. Ez magában foglalja a hagyományos médiaoldalakon közzétett bejelentéseket, jellemzőket, véleményeket és elemzéseket. Ugyanakkor tartalmazhat olyan weblog-bejegyzéseket is, amelyek a nagyon szűk és konkrét érdeklődési körökről szólnak. Az ilyen weblog-ok maguk is számos információforrás összesítői. Az egyik legérdekesebb új szerepek, hogy alakult az úgynevezett lista útmutató. Ez alatt egy specialistát értek, aki figyeli a levelezőlistát vagy a hírcsoportot, és felhívja a figyelmet a jelentős dolgokra, gyakran egy kis elemzéssel csomagolva. Ily módon azok az érdeklődők, akik nem rendelkeznek elegendő idővel és/vagy szakértelemmel a nyers takarmányok feldolgozásához, mégis tarthatják a kapcsolatot a kapcsolódó, vagy akár távoli tudományágak fejlődésével.

3.2 Pushbutton webes közzététel

Bár a HTML egy sokkal egyszerűbb jelölőnyelv, mint mondjuk TeX, A mai Web erősen A tartalom elfogyasztása felé van elfogult, és kevés támogatást nyújt a gyártáshoz. A Web, annak jelenlegi inkarnációja, egy könyvtár, amelyben olvasunk, nem egy hirdetőtábla, amelyen firkálunk. Az internetes alkalmazás, amit a firkáláshoz használunk — végtelenül, termékeny — az e-mail. De míg az e-mail lehet (és gyakran igen) Web tartalom, ez soha nem első osztályú Web tartalom.

Az utóbbi időben számos fronton van mozgás, hogy visszaszerezze a kétirányú, olvasási/írási architektúrát, amely a Web eredeti koncepciója volt. A történet egyik része egy új protokoll neve WebDAV (Web-based Distributed Authoring and Verziószámozás, http://www.webdav.org/, is ismert, egyszerűen, mint DAV), amely lehetővé teszi a kliens alkalmazások tárolja a dokumentumokat közvetlenül a DAV-tisztában Web szerver, zár kinyit a dokumentumok, lekérdezés, vagy állítsa a tulajdonságok parancsra. A DAV-disear kiszolgálók közé tartozik az Apache (mod_dav modullal), a Microsoft Internet Information Server verziója 5, valamint a Digital Creations Zope. A DAV tudatú ügyfelek közé tartozik a Microsoft Office-alkalmazások, valamint az Adobe Go Live, a Web szerzői és tartalomkezelő eszköz.

3.2.1 FTP től WebDAV

Gondolhatunk WebDAV, a jelenlegi formájában, mint egy “jobb FTP”, amely integrálja közvetlenül az alkalmazásokat, így “mentés a weben” egy pushbutton ügy. Támogatja a zárolást, az FTP-nél erőteljesebben kezeli a fájlok mozgatását és másolását. A DAV GYIK megjegyzi ezeket a további előnyöket:

Mivel a DAV a HTTP-n dolgozik, az FTP által nem biztosított HTTP minden előnyét megkapod. Például: Erős hitelesítés, titkosítás, proxytámogatás, gyorsítótárazás. Igaz, hogy ezt az SSH-n keresztül is elérheti, de a HTTP-infrastruktúra sokkal szélesebb körben van telepítve, mint az SSH. Továbbá, az SSH nem rendelkezik az eszközök, a fejlesztéskönyvtárak és a HTTP által használt alkalmazások széles körű kiegészítésével.

Az FTP mélyen beásta magát, és még mindig túlnyomórészt domináns, de a DAV egyre érettebb, és valószínűleg idővel kiszorítja az FTP. Jelenleg kevésbé világos, hogy mi lesz a versioning and configuration management features (http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt) javasolt DAV.

3.2.2 Manila

Manila kétirányú webes megközelítése abból a feltételezésből ered, hogy bár a DAV-kompatibilis írás-és tartalomkezelő eszközök kívánatosak, ezek nem feltétlenül szükségesek. A hagyományos webkiszolgáló szoftverrel támogatott alapböngésző felhatalmazhatja a csoportokat arra, hogy együttműködjenek és közzétegyék együttműködésüket az Interneten.

E célból Manila, többek között, egy Web alapú Vita rendszer. Minden történet vagy Hír elem kiküldött Manila helyén lehet egy indítási pont menetes vita – amely előfordulhat a nyílt, látható minden webhely látogatói, vagy magán, csak a tagok az oldalon.

Manila támogatja a pushbutton web publishing számos módon:

  • Azonnali indítás. UserLand kínál egy ingyenes szolgáltatás, a — www.EditThisPage.com — szóval, hogy bárki indíthat, illetve fuss egy együttműködési weblog, hogy közzéteszi hír, vita egyes érdeklődési terület, integrálja az RSS hírcsatornát. Természetesen megvásárolhatja Manila / Frontier-t, illetve telepítheti saját internetes vagy intranetes webhelyén, de EditThisPage.com azonnali kielégülést nyújt.
  • Élő szerkesztés. A webhely üzemeltetője a minden oldalon megjelenő Edit linket használhatja az oldal letöltéséhez vagy módosításához böngészőűrlapon. A wiki-szerű automatikus formázáshoz korlátozott támogatás áll rendelkezésre, az MSIE-ben pedig egy egyszerű interaktív formatter segít a szerzőknek stílusokat alkalmazni a kiválasztott szövegtartományokban. Általában, bár, Manila nem tetteti, hogy egy teljes körű webes szerzői környezet. A cél az, hogy az ilyen egyszerű írást, amit e-mailben teszünk, a kezelt, illetve szindikált weboldalak birodalmába helyezzük át.
  • Publikációs munkafolyamat. Egy Manila oldal egy bizonyos csoportmunka protokollt testesít meg — egy újságot vagy naplót. Támogatja az elképzelést, a vezető szerkesztő, dolgozik egy csapat közreműködő szerkesztők, hogy készítsen egy patak a történetek, amelyek kifejlesztett belső, megvitatott, szerkesztett, majd megjelent a nyilvánosság számára.
  • Spontán idézés. Az Internet együttműködés egyik legalapvetőbb cselekedete a “FYI e-mail” – egy üzenet, amely hivatkozik, vagy csatlakozik, egy érdekes webes dokumentum. Ez hihetetlenül értékes, hogy képes legyen erre spontán, mint e-mail lehetővé teszi. De van néhány komoly hátránya is. Az FYI e-mail csak a megadott címzetteket célozza meg. Megjelenik az üzenetáramlásukban-túl gyakran, mint a rendetlenség, majd lekúszik az eseményhorizontról. Általában nem hoz létre olyan nyilvános dokumentumot, amelyet más emberek is megtalálhatnak, máskor pedig különböző kontextusokban dolgozik. A Manila, az impulzus mögött egy spontán FYI e-mail lehet-egy kis segítő alkalmazás nevű Manila Express – kifejezni, mint egy spontán cselekmény a web publishing. Vegyük ezt a példát:

5. Ábra: Manila Express

Itt, miközben megtekinti egy asztrofizikai absztrakt MSIE, elindítottam Manila Express (MSIE jobb kattintással elérhető felugró menü). Betöltötte az absztrakt URL-jét a szerkesztési ablakába, és elkezdtem írni egy jegyzéket az idézett papírhoz. Amikor rákattintok a Post gombra, az URL-plusz-jegyzet bekerül a Manila weblogomba, valamint az RSS csatornába. Így egyetlen csapással három közös célt értem el. Először is, értesítettem mindenkit, aki meglátogatja a weblogomat, hogy létezik ez az újság, és a magyarázatom a fontosságáról. Másodszor, lehetővé tettem a papírnak, és az elemzésemnek, hogy egy menetes vita magját alkossa. Harmadszor, már sugározta a citation-plus-analysis az RSS hálózat, hogy az emberek nem közvetlenül hangolt weblog mégis felfedezni ezt a tételt. Hogyan? Fordítsuk figyelmünket az RSS szerzői és kiadói birodalmáról az RSS aggregáció, megtekintés és keresés birodalmára.

3.2.3 Szurikáta

Meerkat névlegesen egy RSS aggregátor és néző. Az RSS-csatornákat több regisztrációból hozza létre, megszünteti a duplikálást, majd egy adatbázisban tárolja az így kapott elemeket. A webes felületen keresztül lekérdezheti az adatbázist. Ebben a példában a Szurikáta az elmúlt 30 napban minden elemet jelent a tudomány kategóriájába csoportosított összes csatornáról, ahol a “fekete lyuk” kifejezés szerepel:

Ábra 6: Szurikáta 

De Meerkat feltalálója, Rael Dornfest, is tette azt az eszközt, amely egyszerűsíti kiadói, valamint megtekintésére, készletek RSS elemek. A regisztrált felhasználók kétféle névgyűjteményt adhatnak meg. A profil egy tárolt lekérdezés. Így például a Szurikáta URL http://meerkat.oreillynet.com/?p=739 megnevez egy lekérdezést, amely megkérdezi: “mutasd meg az összes elemet Jon Udell csatornájából.”A maffia egy önkényes gyűjtemény. A felhasználó meghatározhat egy ilyen gyűjteményt, megadhat neki egy nevet, mint például a “BlackHole”, majd hozzárendel elemeket bármely csatorna hozzá kattintva az elem kör alakú ikonok. A profilokhoz hasonlóan a okat is olyan URL-ek képviselik, amelyeket e-mailben vagy weboldalakon is meg lehet osztani.

Szurikáta-felhasználó számára a tárolt lekérdezések kezelése, illetve a megnevezett gyűjtemények kezelése egy kattintásnyira lévő esemény. De tegyük fel, hogy újra meg akarja ismételni az RSS hírek nézetét? A szurikáta számos olyan felületet támogat, amelyek megkönnyítik az általa kezelt tartalom újrahasznosítását. Megkérheti például a Meerkat-et, hogy ugyanolyan RSS formátumban készítsen kimenetet, mint amit elfogyaszt. Ebben a módban a Szurikáta tiszta szűrőként működik. ez az egyik lehetséges fázis az információ-finomító vezetékben. Ez egy kritikus pont. Az XML egyaránt fogyasztó és előállító alkalmazások és szolgáltatások automatikusan újrafelhasználható komponensek, amelyek kombinálhatók és újraegyesíthetők, hogy új hatásokat teremtsenek. Nem valószínű, hogy egyetlen “gyilkos app” a realm of Internet groupware. Inkább, lesz egy “gyilkos infrastruktúra” – alapú egyetemes ábrázolása adatok XML — amely lehetővé teszi egy egész osztály speciális, ad-hoc alkalmazások ugyanúgy, mint a UNIX csővezeték tette.

A Meerkat nézet weblapon történő bemutatásához a Meerkat-et is megkérheti, hogy XML az HTML tegye. Ez XML az HTML átalakítás azért szükséges, mert nem minden böngésző képes XML közvetlenül megjeleníteni. De annak a korszaknak a végéhez közeledünk. Az Internet Explorer már meg tudja csinálni. Ahogy az új Mozilla.

3.3 Az RSS technológia jelentősége

Az RSS széles körben az XML egyik legsikeresebb alkalmazásának tekinthető. Az egyik ok, kétségtelenül, hogy ez egy nagyon egyszerű alkalmazás XML. Olyan eszközökre koncentráltam, amelyek automatizálják az RSS csatornák létrehozását és használatát, de valójában ezek az eszközök nem kötelezőek. Itt egy cikk a saját csatornámról:

<item>
<title>
Talk | MathML
</title>
<link>http://www.byte.com/nntp/applications?comment_id=7158#thread</link>
<description>
There appears to be strong progress on the MathML front.
The w3c working draft (version 2) is in last call, and it
is one of more beautifully written documents of its type
that I’ve ever seen.
</description>
</item>

Mint maga a HTML, RSS könnyen kézzel írható. Így ugyanolyan könnyű olyan eszközöket létrehozni, amelyek különböző formátumokat RSS-vé alakítanak át. A HTML az RSS-tartalmak egyszerű és megbízható módon elemezhetők bármilyen XML-felismerő szkriptnyelvvel. Így könnyű olyan eszközöket készíteni, mint a Meerkat, amelyek rögzítik, megszervezik és növelik az RSS áramlását.

Az RSS hálózat értéke természetesen a benne folyó hírek jellegétől és minőségétől függ. A “technológia/számítógép/geek” közösségben, ahol az RSS fejlődött, erőteljes, jól megalapozott, átfogó rendszerré vált, amely a figyelmet a vezető fejlesztésekre összpontosítja. Az olyan eszközök, mint a Manila és a Meerkat, gyorsan fejlődnek, olyan módon, hogy a rendszer előnyeit más, rájuk szoruló közösségek, köztük számos tudományos közösség számára is elérhetik.

Az információ túlterhelése súlyos probléma, és nincs egyetlen legjobb megoldás sem. Az RSS-hálózaton szindikált weblogok sem immunisabbak a jelromlásra, mint az Usenet volt. Az XML önmagában nem változtat semmin. Ami új, és reményteli, az egy általános formátumú tartalom szindikáció fogalma. Ez a szabvány lehetővé teszi egy új osztály információ-finomító eszközök. Ezek az eszközök lehetővé teszik az emberek számára a keresést, a kijelölést, a megjegyzéseket, valamint a Web kaotikus áramlásának könnyebb és hatékonyabb átszervezését, mint az egyébként lehetséges.

4 Tudományos Kiadás

A tudományos publikáláshoz még nincs elfogadható alternatíva a TeX/LaTeX, Word és FrameMaker számára. De jobb megoldások vannak kilátásban, amelyek mind a tartalom XML-ben való szabványos ábrázolása körül forognak. Bár a kiadói iparág elvben az XML-t választotta egyetemes formátumként, a gyakorlatban még nem sok XML-t írt. Amikor Web felülvizsgálat (http://www.webreview.com/) megkérdezte a közönség a Web-hozzáértés szerzők és fejlesztők, hogy hányan írtak XML, több mint a fele azt válaszolta, hogy “nem tudom, hol kezdjem”, és csak 15% azt mondta, “rendszeresen használja” (http://webreview.com/wr/pub/2000/06/23/poll/results.html).

Kevesen érvelhetnek egy XML-tudatú írószerszám velejáró előnyeivel szemben. Vegyük például azt, hogy TeX miért népszerű. Matek tördelő része az oka, de TeX képes átalakítani bibliográfiai jelölést a különböző formátumok által előírt folyóiratok egy másik kulcsfontosságú erejét.

Ki ne akarna egy WYSIWYG XML szerkesztő, amely:

  • interaktívan dolgozunk szöveggel, egyenletekkel és illusztrációkkal
  • a szükséges formátumok megértése és érvényesítése
  • as tartalom könnyű és automatikus átdolgozásának garantálása
  • olyan anyaggal dolgozni, amely mindig szerkeszthető, mégis mindig Web kész

Az MS Word még nem tesz ilyet, de a Microsoft Júniusi 2000 bejelentése XML-alapú “.NET platorm” (http://www.microsoft.com/presspass/topics/f2k/presskit.asp) azt sugallja, hogy a szó elkerülhetetlenül fog. Eközben a többi árus előre tör. 1999-ben SoftQuad (http://www.softquad.com/) új alap az első megfizethető WYSIWYG XML szerkesztő, XMetaL. Korábban az ilyen eszközök piacát több ezer dolláros SGML eszközök uralták, XML képességgel átépítve, olyan vállalatoktól, mint az ArborText (http://www.arbortext.com) és Inso (http://www.inso.com). XMetaL, egy $ 500 ablak asztali alkalmazás, biztosítja sok előnye a high-end eszközök.

Az XMetaL WYSIWYG módban úgy ír, mint bármely szövegszerkesztő. Az XML-tartalom megjelenítését CSS stíluslap vezérli. Minden, amit az XMetaL ír, szintén érvényesül — interaktívan — egy DTD (dokumentumtípus-definíció) ellen. Adott egy DTD, hogy leírja az elemeket, hogy előfordulhat, hogy egy tudományos újságban, a sorrend alapján, amelyben ezek az elemek is előfordulhat, XMetaL segít, hogy hozzon létre egy megfelelő dokumentum, amelyben az elemek, amelyek érvényes az adott összefüggésben, mint egy programozó szerkesztő lehet kérni az érvek, hogy a jogi át funkció.

Mint az új generációs böngészők (MSIE 5, Mozilla), XMetaL is egy eszközkészletet fejlődő tartalomorientált alkalmazások. Ez egy W3C Dokumentumobjektum-modell (DOM) felületet biztosít az általa kezelt tartalomhoz, és egy univerzális parancsfájl-kezelőfelületet csomagol a DOM köré. Mivel az XMetaL ActiveX scripting host, a szkriptek bármilyen megfelelő szkriptnyelven írhatók, beleértve a VBScript, JavaScript, Perl vagy a Python. Az ilyen szkriptek többek között “varázslók” létrehozására használhatók, amelyek segítenek a felhasználóknak DTD által előírt formátumokba írni. És ez a döntő pont. A tudományos dolgozatok bibliográfiáját meghatározó DTD önmagában csak egy passzív szabályrendszer, amelyet meg kell tanulni és követni kell. Az emberek nem fogják elfogadni az XML-orientált írószerszámokat, ha elvárják tőlük, hogy egy másik passzív szabályrendszerét helyettesítsék. Az emberek olyan eszközöket fognak használni, amelyek segítenek nekik végrehajtani a szükséges protokollokat. A bibliográfiai hivatkozás csak egy példa egy ilyen protokollra. Megértve, gyakorlatilag minden cselekmény írásbeli kommunikáció – egy szoftver hibajelentést, egy megjegyzést a tervezetet a papír, egy e-mail üzenetet kér intézkedést egy bizonyos elem egy bizonyos időpontig-található, koncepcionálisan, belül egy szabály-alapú protokoll.

Az internetalapú együttműködés jövője nagymértékben függ attól, hogy a szoftver képes-e ezeket a protokollokat megtestesíteni. Ebben a tekintetben az XML szerepe, mint univerzális tároló és csere formátum, csak a történet felének a fele. Ugyanilyen fontos, hogy ki tudja fejezni és érvényesíteni az együttműködés szabályait. De nem érheti el ezt a célt, amíg bele nem szövődik a mindennapi élet szövetébe. A strukturált írás nem tud, és nem is fog, továbbra is egy speciális tevékenység. Automatikusan kell áramlania a frontline alkalmazások normál használatából-szóprocesszorok, e-mail kliensek, amelyek rögzítik a legtöbb szót, és előállítják a legtöbb, amit tudunk.

A rossz hír az, hogy az infrastruktúra ilyen nagyságrendű változása nem történhet meg gyorsan. A jó hír azonban az, hogy most már általános konszenzus van a változás megvalósításának módjáról, valamint a közelmúltban történt sok bizonyítható előrehaladásról. Hogy pontosabban szemléltessük ezt, vegyük figyelembe, hogy két adattípus a tudományos együttműködés központi eleme-egyenletek és diagramok-a feltörekvő kétirányú háló szövetébe Web.

4.1 Matematika az Web

A tudósok számára fájdalmasan ironikus, hogy a Web, feltalált kifejezetten, hogy segítsen nekik együttműködni, még mindig hiányzik erős támogatása az egyik elsődleges formája a tudományos diskurzus: matematikai egyenletek. Ennek eredményeként, matematikai tartalom általában szállított az interneten az egyik a számos nem kielégítő módon. Az egyenletek megtekinthetők HTML-fájlokban, PDF-fájlokban vagy Java-nézőben (pl. WebEQ) vagy szabad vagy kereskedelmi plug-inben (pl. LiveMath, IBM techExplorer). Minden ilyen esetben azonban az egyenletek idegen adattípusként végzik. Dolgok, amit nem lehet csinálni ezzel a külföldi tartalom:

  • Egyenletek írása hagyományos HTML-készítő eszközökkel.
  • Vágja és illessze be őket könnyen, ha egyáltalán.
  • Kutassátok át őket és a környező szövegüket egyszerre.
  • Stílus őket, valamint a környező szöveget.
  • Hiperlinkforrásokat és célpontokat csatolunk hozzájuk.
  • Csatolja a megírt viselkedést hozzájuk.

Évek óta arról beszélnek, hogy a matematika létrehozásának és megjelenítésének egy sokkal natívabb módja is van. Ezek az erőfeszítések most kezdenek gyümölcsözővé válni. A második változata a W3C working draft of MathML (http://www.w3.org/TR/2000/WD-MathML2-20000328/) az XML matematika-orientált alkalmazása az “utolsó hívás” szakaszban van, és mind a kereskedelmi gyártók, mind a nyílt forráskódú közösség felsorakozik annak támogatására.

Miért a lassú kezdet? A már meglévő eszközöket, nevezetesen Donald Knuth TeX — egy szuperlatív és széles körben használt rendszert a matematika tipizálására és összetételére , nem volt könnyű integrálni a Web eredeti modelljével. Az XML csak nemrég határozták meg szilárdan az Internet kiterjesztésének általános stratégiájaként. Ez egy dolog, hogy beágyazni egy külföldi darab matematika egy HTML oldal, mint ez:

Abra 7: Külföldi matematika 

<p>
As you can see from this example:
</p>

<embed src="SomeMathPlugin">

<p>
, the result...
</p>

Ez valami más, hogy szőni a matematika egyenesen a szövet az oldal, mint ez:

Abra 8: Natív matematika 

<p>
As you can see from this example:
<math>
  <mfrac style="font-size: 14pt">
    <msqrt>
      <mi href="/definitions#k" xml:link="simple">k</mi>
    </msqrt>
    <msup>
      <mi>m</mi>
      <mn>2</mn>
    </msup>
  </mfrac>
</math>
, the result...
</p>

Megjegyzés: az <mfrac> elemhez csatolt stílus attribútum. Megjegyzés: a K kifejezés hogyan kapcsolódik egy címhez (/definíciók#k), így az egyenlet olvasója a k-re kattintva többet megtudhat róla. Ez az a fajta mély és folyékony integráció, amit a “matematika a Web” kifejezés a képzeletünkben idéz elő. És most kínosan közel van a valósághoz. Nem csak Abrán 8 vettem ki a jelet a semmiből. Én rögzítette a Nézet forrás ablakban Amaya (http://www.w3.org/Amaya), a W3C testbed böngésző. Amaya mutatja az egyenletet Abrán 8:

Abra 9: Amaya renderelés MathML 

Egyértelműen Amaya teszi a betűtípus stílus attribútum csatolt frakció. De néhány dolog nem nyilvánvaló ebben a jelenetben. Először is, a hiperhivatkozás, ami a k-ra van tekerve, tényleg működik. Másodszor, Amaya nem csak néző, hanem szerkesztő is. Minden, amit megjelenít — a szöveg és az egyenlet — szerkesztésre is alkalmas.

Amaya esetében az ilyen szerkesztés WYSIWYG módban történik. De egy hatékony eszköz is könnyen elfogadhatja TeX markup, mint sok tudós képzett írni. A lényeg nem az, hogy egy dokumentum webes változatát hogyan szerkesztik, hanem az, hogy közvetlenül szerkeszthető.

Jelenleg verzió 3.2, Amaya közel sem elég stabil, vagy elég teljes az igazi munkához, de ez egy mámorító pillantás, hogy a dolgok kell lennie. Amellett, hogy MathML, mellékesen, az XHTML képességek figyelemre méltó. Használhatja a “Mentés másként XHTML” funkciót, hogy automatizálja a grunge munka átalakítása egy fájlt a normál HTML egy fájlt a jól formázott és fenntarthatóbb XHTML.

4.1.1 Az összetett dokumentumokon túl

Az OLE és az OpenDoc megjelenése óta arra törekszünk, hogy “dokumentumközpontú” számítástechnikát alkalmazzunk. Már nem akarjuk, hogy a GUI windows monolitikus dokumentumokat képviseljen egyetlen alkalmazással. Azt akarjuk, hogy olyan heterogén dokumentumokat tartalmazzanak, amelyek feladatorientált tevékenységeket képviselnek, és amelyeket együttműködő alkalmazások csoportja támogat. Míg az olyan technológiák, mint az OLE beágyazás, lehetővé tették az ablak számára, hogy szöveges, grafikus és táblázatos összetevők keverékét tartalmazza, ezek mindegyikét egy olyan alkalmazás támogatta, amely az adatokat a saját védett módján képviselte. Össze lehet keverni az összetevőket az oldalon, és adatokat továbbítani közöttük a DDE vagy a vágólap segítségével, de nem igazán lehet őket összeolvasztani. A modell inkább Abra 7 volt, mint a Abra 8.

Mi indokolja az összes XML hype az, hogy ígéri, hogy alapvetően egyesíti az adatok képviseletét. Amikor egy oldal tartalmaz egy darab XHTML szöveget, és egy rakás MathML egyenletet, és egy darab SVG grafikát, az nem csak egy vászon, három dologgal ráragadva. Háromféle szálból szőtt szövet. Az egyes szálakhoz tartozó szöveges elemek ugyanazon keresési és stílusmechanizmusok hatálya alá tartoznak. Minden elem a DOM (document object model) része, így a parancsfájlok vezérlésére is rendelkezésre áll.

Annak megértéséhez, hogy miért számít az egyetemes adatküldés olyan sokat, kérdezd meg magadtól: “Miért sikerült a UNIX-nak?”A részvényválasz az, hogy a UNIX feltalálta a szoftveralkatrészek ötletét, amely könnyen megoldható számos hasznos módon. De mi tette ezt lehetővé? Az összetevők megegyeztek abban, hogy az adatokat vonalorientált szövegként jelölik ki, amelyeket a fehértérrel határolt tokenek tartalmaznak. Ez lehetővé tette egy csomó ragasztó technológia-a kagylók, sed, awk, Perl. Most egy új generációs ragasztótechnológiát látunk, amely egyetért az XML által nyújtott sokkal gazdagabb adatmegjelenítéssel. A webszolgáltatások összekapcsolásához ezek az XML-vége-HTTP protokollok gyorsan de facto szabványsá váltak. A következő határ olyan webes alkalmazások lesznek, amelyek túlmutatnak a Abra 7 összetett dokumentummodelljén, és megegyeznek a szabványos XML adatmegjelenítésben, amely lehetővé teszi a különböző adattípusok keveredését és kölcsönhatását.

4.1.2 Mozilla és MathML

Mozilla projekt nagyon komolyan veszi a MathML. A MathML-támogatás még nem szerepel a szabványos felépítésben, de ha ki szeretné próbálni, letöltheti a Mozilla MathML-kompatibilis verzióját (http://www.mozilla.org/projects/seamonkey/release-notes/). Ellentétben Amaya, Mozilla nem (még) egy MathML szerkesztő, csak egy néző, de mint ilyen, hogy óriási előrelépés. Érdekes, hogy amint egy előrehaladási jelentés (http://www.mozilla.org/projects/mathml/update.html) Roger Sidje, egy kulcs (nem Netscape-vállalkozó) közreműködő, MathML az első jelentős Mozilla alkatrész hajtott teljes egészében a külső érdekek elkötelezetlen a Netscape üzleti prioritásokat.

Mozilla MathML első célja, hogy kihasználja a böngésző új elrendezési motorját (“Gecko”). E célból a tartalomfelméréssel szemben a prezentációs jelölésre fog összpontosítani. Mi a különbség? Az előbbi olyanokat mond, hogy “tegyél ide egy sor elemet, aztán alatta egy dobozt, amiben ezek az elemek vannak.” Az utóbbi mond dolgokat, mint “alkalmazni ezt a műveletet ezekre az alexpressziók.” W3C munkafolyamata magyarázza:

Mind a tartalom, mind a bemutató címkék szükségesek ahhoz, hogy a teljes kifejező képesség elvárható egy matematikai jelölőnyelv. Gyakran ugyanazt a matematikai jelölést használják, hogy képviseljen több teljesen különböző fogalmakat. Például a xi jelölést (polinom algebra) az x változó i-edik erejeként, vagy x vektor i-edik komponenseként (tensor kalkulusban) lehet használni. Más esetekben ugyanaz a matematikai koncepció jelenhet meg az egyik különböző jelölések. Például egy szám faktoriálját felkiáltójellel, Gamma funkcióval vagy Pochhammer szimbólummal lehet kifejezni.

Így ugyanaz a jelölés több matematikai elképzelést is képviselhet, ezzel szemben ugyanannak a matematikai eszmének gyakran több jelölése is van. Annak érdekében, hogy a szerzők képesek legyenek pontosan szabályozni a jelölést, miközben a kódolás gépileg olvasható módon történik, mind a tartalom, mind a prezentációs jelölés szükséges.

Mély finomságok vannak itt. Néha bemutató markup beágyazza belül tartalom jelölést, így az alkalmazás kap tippeket arról, hogyan tehetik egyenletek; néha tartalom markup beágyazza belül bemutatása markup, hogy meghatározza, hogy milyen matematikai jelentése, célja; néha a két fordulhat elő, ezzel párhuzamosan, ha a kapcsolat tartalma, prezentáció nem lehet könnyen vezethető le. Még a speciális matematikai szoftver, mastering e finomságok sokáig fog tartani. Hogyan versenyezhet a Mozilla? Nem is kell. A MathML támogatás célja, hogy segítsen az embereknek kommunikálni matematikailag az Web, összhangban ezzel a kiváló küldetés nyilatkozatot a W3C:

Gyakorlati szempontból az a megfigyelés, hogy a matematika az Web, kell biztosítani mind a speciális, mind az általános igényeket természetesen vezet az ötlet egy rétegzett architektúra. Az egyik réteg erős, általános szoftvereszközök cseréjéből, feldolgozásából és megfelelően kódolt matematikai adatokból áll. A második réteg olyan speciális szoftvereszközökből áll, amelyek meghatározott felhasználói csoportokra irányulnak, amelyek könnyen generálhatnak kódolt matematikai adatokat, amelyeket aztán meg lehet osztani egy adott közönséggel.

MathML célja, hogy a kódolás matematikai információk az alsó, általánosabb réteg egy kétrétegű architektúra. A célja az, hogy kódolni komplex kiegészítő megjegyzések, valamint a szemantikai struktúra kifejezett, rendszeres, egyszerű folyamat, ahogy a megjelenítőnek, keresés, indexelés szoftver, valamint az egyéb matematikai alkalmazások.

Ennek fényében a cél, fontolja meg ezt a screenshot írt news://news.mozilla.org/netscape.public.mozilla.mathml, amely egy e-mail üzenet összetételét illusztrálja, amely összekeveri a szöveges és matematikai tartalmat:

Abra 10: MathML kompatibilis Mozilla 

Ez a kép a dolgok rendjéről szól! És nem csak a matematika a weben, hanem mindenféle tartalom. A tudományos együttműködés a szöveg, grafika, matematika és más adattípusok közötti folyamatos diskurzus. Miért ne e-mail, a médium, amelyen keresztül annyi a beszélgetés folyik, natívan megérteni ezeket az adattípusokat? Pedig kellene. Ez az inspiráló pillantás a jövőre emlékeztet bennünket arra, hogy a 65 karakter vonal ASCII-art email üzenet napjai elkerülhetetlenül meg vannak számlálva.

4.2 SVG: PostScript a Web

Amikor a TeX-ben írt tudományos dokumentumok diagramokat és illusztrációkat tartalmaznak, ezek idegen (jellemzően PostScript) objektumként vannak beágyazva a TeX forrásfolyamba. Egyszer megjelent PDF, mint most történik a kereslet a papírokat írt a fizika e-print archívum at www.arxiv.org, a szöveg, egyenletek, illusztrációk úgy tűnik, hogy egybeolvadnak egy bemutatóval. De a PDF fájlok Web első osztályú polgárok a Web környezetben. Mint a szöveges fájlokba beágyazott PostScript objektumok, a PDF fájlok maguk is olyan idegen objektumok, amelyek nem integrálódnak natívan a “universal canvas” az interneten.

Microsoft akkor találta ki az “univerzális vászon” kifejezést, amikor bejelentette a következő generációs platformját .NET. A kifejezés egyetlen megtekintési és szerkesztési felületet jelöl, amelyen a heterogén adattípusok folyékonyan kölcsönhatásba lépnek. Ezeket az adattípusokat a szöveg, egyenletek, illusztrációk speciális szolgáltatásai támogatják. De mivel minden közös XML megjelenítéssel rendelkezik, vannak közös szolgáltatások is a kereséshez és a jegyzeteléshez.

Tekintsük ezt az egyszerű sáv diagram:

Abra 11: Egyszerű diagram 

Ha ezt a diagramot nyomtatott jelentésbe szeretné foglalni, raszterizálnia kell a képet. Ugyanez a raszterizált kép beágyazható a jelentés online, HTML alapú változatába, de:

  • Nem keresheti vagy választhatja ki a diagramon lévő szöveget ugyanúgy, mint ahogy a keresést végzi, vagy a diagramot embedizáló jelentés szövegét.
  • Nem lehet újraírni a diagramot, hogy több (vagy kevesebb) részlet. Ez nem egy kérdés ebben az egyszerű esetben, de a komplex illusztrációk szeretné használni az információt skálázható vektor formátumban, nem raszterizált (bitmapped) formátumban.
  • Nem tudsz linket eleme a táblázat, így például egyes adatok vezet oldalán az alátámasztó részletek, vagy egy bemeneti mechanizmus, amely összegyűjti kommentárok adott elem.
  • Nem lehet összekapcsolni a térkép elemeivel. Egy összetettebb illusztráció, lehet, hogy több nézet. Ideális esetben ezeket meg kell nevezni, az illusztrációnak pedig exportálnia kell ezt a névteret, hogy összetevői nézeteire közvetlenül hivatkozhasson.

A diagram PDF változata, amely a jelentés online verziójában szerepel, ezeket a képességeket biztosítja. Méretezhető, és támogatja a kimenő kapcsolatokat. De nem támogatja a közvetlen bejövő hivatkozásokat, és ha a tároló HTML, akkor nem fog nagyon jól integrálni azzal a konténerrel.

Ha a HTML kezelni tudná a vektorgrafikát, az megoldaná ezeket a problémákat. Valójában a HTML képes egyszerű vektorgrafikára, így készült ez a diagram:

    <H2>Current disk quota usage by team<br>(updated every hour)</H2>
    <H3>Production Volume (/dev/vx/rdsk/production/vol01:)</H3>
      <TABLE CELLPADDING=2>
        <TR>
          <TD ALIGN=RIGHT><B>MB Max</B></TD>
          <TD ALIGN=RIGHT><B>MB Used</B></TD>
          <TD><B></B></TD>
          <TD ALIGN=RIGHT><B>% Used</B></TD>
          <TD><B>Team</B></TD>
        </TR>
        <TR>
          <TD ALIGN=RIGHT> 175104.00</TD>
          <TD ALIGN=RIGHT> 101141.60</TD>
          <TD>
            <TABLE CELLPADDING=0 CELLSPACING=0 BORDER=0>
              <TR>
                <TD BGCOLOR='#003366' WIDTH=115 HEIGHT=15></TD>
                <TD BGCOLOR='#CCCCCC' WIDTH=84></TD>
              </TR>
            </TABLE>
          </TD>
          <TD ALIGN=RIGHT> 57.8%</TD>
          <TD>RETAIL</TD>
        </TR>

Nyilvánvaló, hogy a HTML primitív vektor grafika nem tudja támogatni még a pite diagramok, nem beszélve telek egyenletek. De a konszenzus most jelenik meg, hogy SVG (skálázható Vektorgrafika, http://www.w3.org/Graphics/SVG/) készen áll arra, hogy kifinomultabb vektor grafika oly módon, hogy megőrzi az előnyöket a HTML Web-natív megközelítés. Az Adobe kiadta az SVG viewer 1.0 verzióját. Itt van egy kép egy SVG változata az azonos diagram, megtekinthető MSIE az Adobe SVG plugin.

Abra12: SVG verziója megtekintett taz Adobe plugin 

A chart SVG verziójának létrehozása olyan, mint a HTML-verzió létrehozása, ami nagyon jó dolog. Mint a HTML, vannak mindenféle építési technikák: lehet írni a cuccot kézzel egy szövegszerkesztő, akkor írhat szkriptek automatizálni részeinek a folyamat, vagy használhatja WYSIWYG szerkesztők építeni interaktívan. A webfejlesztők, akik már ismerik a CSS stílusát, megírt, sablonvezérelt HTML-konstrukciót, azonnal produktívnak találják magukat az SVG.

Annak érdekében, hogy egy érzés, hogy mi van benne, elkezdtem építeni ezt SVG példa Jasc Software röppályája Pro (http://www.jasc.com/trj.asp), egy új WYSIWYG vector-illusztrációs eszköz, amelynek natív formátuma SVG. De bárki, aki ismeri a HTML lehet, hogy egy egyszerű diagram, mint ez, használja egyik SVG fejlett hatások-utak, gradiensek, szűrők-WYSIWYG eszköz nélkül. Itt egy darab SVG egy címkéhez és a hozzá tartozó párhoz:

Abra 13: SVG fragmentum elemcsoporthoz 

<g transform="translate(1in,100)">

<text style="text-anchor:end; font-size:15; 
  font-family:Arial" x="0" y="20">retail</text>

<rect style="stroke:#000000; fill:lightgray" 
  x="70" y="0" width="400" height="20"/>

<text style="text-anchor:end; font-family:Arial; 
  font-weight:bold" x="60" y="15">275104</text>

<rect style="stroke:#000000; fill:#ccffcc" x="70" y="20" 
  width="147" height="20"/>

<text style="text-anchor:end; font-family:Arial; 
  font-weight:bold" x="60" y="35">101141</text>

</g>

Az SVG egy darabja, mint Abrán 13, legyen szó szerszámról vagy kézzel írottról, parameterizálást akar, így automatikusan megismételheti variációkkal. Ez egy forgatókönyv. A megszokott idió, amit oly gyakran használnak, hogy automatizálják a HTML konstrukciót — templatize egy darab markup, majd hurok keresztül egy adatszerkezet populáló példányai a sablon-ugyanúgy működik SVG.

Az Adobe viewer segítségével igazi vektorképünk van. Nagyíthat, kicsinyíthet, körbepásztázhat, nagy hűséggel nyomtathat.

Természetesen egy SVG plugin nem több egy web-natív eszköz, mint a PDF plugin. De natív böngésző támogatása SVG jön. Itt például egy korai pillantást egy SVG-kompatibilis változata Mozilla:

Abra 14: SVG-kompatibilis Mozilla 

Vannak önálló SVG nézők is. Java nézők közé tartozik a CSIRO SVG Toolkit (http://sis.cmis.csiro.au/svg/) and IBM SVGView (http://www.alphaworks.ibm.com/tech/svgview). Natív Linux nézők közé Raph Levien Gill (http://www.levien.com/svg/) and Lauris Kaplinski SodiPodi (http://sodipodi.sourceforge.net/).

Rövid távon a beágyazott PostScript illusztrációkkal rendelkező TeX fájlokból készült PDFs továbbra is széles körben használható, hasznos lehet. Ugyanez igaz a raszterizált illusztrációkat beágyazó HTML-dokumentumokra is. De SVG (vagy valami nagyon hasonló) fog érvényesülni, mert hosszú távon az előnyök az egyetemes vászon ellenállhatatlan. Az SVG illusztráció nem csak egy weblapra ragadt valami, hanem egyenesen az oldal szövetébe van szőve. Bárhol kereshet szöveget. Az SVG elemekből kapcsolódhat más tartalmakhoz. Vagy kapcsolódhat SVG elemek máshonnan. Mint egy HTML oldal sok megnevezett régióval, az SVG egy része is exportálhat egy névteret, amely meghatározza a bejegyzési pontokat több nézetre.

4.2.1 XML szerkesztők és univerzális vászon

Egy gondolatébresztő esszében (http://www.excosoft.se/indexns.html), Jan Christian Herlitz, R&D igazgató a ExcoSoft, megjegyzi, hogy egy táblázatot lehet képviselni XML, mint ez:

<CELL id=”B40″>262</CELL>

Érvek Jan:

Ez azt jelenti, hogy az Excel azért XML szerkesztő, mert az adatokat XML-ben tárolja? Vajon a mai XML szerkesztők táblázatkezelő eszközök lesznek, ha el tudják olvasni az Excel fájlokat? Mindkét kérdésre a válasz határozottan nem! A táblázatszerkesztőnek az XML-kódot cellákkal és képletekkel fel kell térképeznie egy munkafüzet adatstruktúrájára, ki kell számítania az eredményeket, és az eredményeket a tipikus táblázatkezelő módon kell bemutatnia. 

A szerkesztők következő generációja elolvassa és bemutatja az XML-alapú információkat, legyen szó bekezdésekről, táblázatokról, rajzokról, e-mailekről vagy táblázatokról. Minden egy felhasználói felületen történik. A helyszín mögött a különböző gyártók különböző szoftverösszetevői lesznek aktiválva az információ különböző részeinek kezelésére. Integráció érhető el a “stílus”. Egy elem például táblázatkezelőként kerül kialakításra. A rendszer egy táblázatkezelő összetevőt hoz létre az adatok kiszámításához és bemutatásához. Mivel minden alapvetően XML, a felhasználó egy sokkal egyszerűbb, természetesebb felhasználói felületet fog tapasztalni. Minden típusú információ tárolható egy dokumentumban (külön entitások nem szükségesek). A szöveget egységes módon kezelik. Mindent át lehet kutatni. Mindent meg lehet tervezni. Minden benne lehet minden másban; egy egyenlet az asztal belsejében, ami egy rajzban van, ami egy táblázatban van. 

A szerkesztők következő generációja mind szerkesztők, mind böngészők lesz, de nem értelmezhető értelemben XML szerkesztők lesznek. Ők csak ügyfelek lesznek! 

Minden összefügg az XML ben található univerzális adatmegjelenítéssel. Megyünk túl OLE stílus beágyazás, egy birodalom, ahol datatypes keverék közelebbről meg, ahol a hagyományos eszközöket, technikákat alkalmazni, hogy olyan keverékek ezek datatypes. Az SVG még nem áll készen a főműsoridőre, de úgy tervezték, hogy támogassa a Web alapú együttműködést oly módon, hogy a PDF nem.

5 Záró Ajánlások

Az “univerzális vászon” egy kedves ötlet, hogy mi, reméljük, egy nap majd magától értetődőnek vesszük. De mi a jelenben élünk. Bár szeretjük azt hinni, hogy futunk az “Internet idő” az eszközök rendelkezésre álló együttműködés lassan változik, mint ahogy a kultúra környező az eszközök használatát.

Az e-mail mindig is az internetes együttműködés alapvető eszköze volt, és még mindig jogszerűen megmarad. De most jön létre egy osztály Web-alapú szolgáltatások, amelyek növelhetik vagy helyettesítheti e-mail bizonyos típusú együttműködés, mint például az esemény ütemezés (pl. TimeDance) vagy vita (pl. QuickTopic). Ezek a szolgáltatások mind azért jelentősek, mert azonnali gyakorlati igényeknek felelnek meg, mind azért, mert-mivel webalapú szolgáltatások-új, ad-hoc együttműködési megoldások építőelemeként működhetnek. Az Interneten olyanok, mint a grep és a barátok a UNIX-nak. újrafelhasználható összetevők, amiket meg lehet állítani.

A jelentés webes változata ([végső URL]) az egyik ilyen pipelt megoldást szemlélteti. A dokumentum forrása az XML a legegyszerűbb formájában-azaz a HTML, amely betartja az XML megfelelőséghez szükséges néhány szabályt. Így könnyen átalakítható egy továbbfejlesztett renderelés, amely “eszközök” az együttműködés. Itt egy kép a továbbfejlesztett renderelésről:

 Abra 15: Jelentés együttműködéssel felülvizsgálható változata 

Az egyes bekezdéseket követő számozott linkek azt jelentik, hogy a dokumentum minden egyes helye pontosan hivatkozható. A linkekhez kapcsolódó intézkedések támogatják a dokumentum együttműködésen alapuló felülvizsgálatát. Abrán 15 szereplő hivatkozások egyikére kattintva ez az űrlap jelenik meg:

Abra 16: Jelentéssel kapcsolatos észrevételek formanyomtatványa

Az űrlap viszont hozzászólások egy megjegyzést a QuickTopic vitatér:

Abra 17: Jelentés tárgyalási helye 

Ebben a vitafórumban egy megjegyzés a dokumentumra utal, annak a dokumentumnak a helyére, amely a megjegyzést kiváltotta.

Itt nem az a fontos, hogy hogyan működik. A lényeg a következő:

  • Nem volt nehéz megszervezni ezt a hatást. Jól strukturált tartalom, még a legegyszerűbb fajta, kialakulóban lévő tulajdonságokkal rendelkezik. Könnyen és természetesen átalakul olyan formákká, amelyek támogatják a Web alapú együttműködést.
  • Bármely Web vitakomponens támogathatja a hatást. Bár én már használt QuickTopic itt, én is olyan könnyen lehetett volna használni bármilyen vita eszköz, amely lehet csatlakoztatni, amit nevezhetünk “Web csővezeték.” A legtöbb Web szolgáltatásnak automatikusan megvan ez a tulajdonsága, csak azért, mert azok webböngészők, amelyek az interaktív böngészők és a programozott szkriptek számára egyaránt hozzáférhetők.
  • Az XML-írási eszközök hiánya kritikus szűk keresztmetszet. Az írószerszámok, amiket minden nap használunk — szóprocesszorok, e-mail kompozerek — rögzítik az internetes együttműködés alapanyagainak nagy részét. De még nem rögzítik az anyagot XML ként. Igaz, hogy egy tudósnak, aki elsajátította a TeX vagy a LaTeX, a jelentés megjelölt forrása gyerekjáték. De senki sem kell elvárni, hogy komponálja markup közvetlenül. A tudósok elvárják, és követelik, hogy a mindennapi írás-és üzenetküldő eszközeik szövegeket, egyenleteket és illusztrációkat dolgozzanak fel WYSIWYG módon, és az anyagot univerzális szabványformátumban képviseljék, ami lehetővé teszi az új, szemcsésebb, hozzáférhetőbb és erősebb együttműködési formákat.
  • Web szolgáltatások már támogatja a jobb együttműködés. Az XML tudatú írószerszámok, amelyekre szükségünk van, túl lassan haladnak. De sok mindent el lehet érni nélkülük. A jelentés tárgyalási helye még az XML-alapú elemszintű kereszthivatkozás nélkül is rendkívül hasznos lenne. Manapság sok lehetőség van arra, hogy az együttműködést közös terekbe helyezzék. Ez segíthet enyhíteni néhány problémát hozunk létre egymásnak, amikor kényszerítjük e-mailt, hogy vigye az egész terhet.

5.1 A kétirányú Web

Az Internet groupware célja, hogy visszaszerezze az eredeti elképzelés a weben, mint egy közeg az együttműködés. Nem véletlen, hogy a látomás egy tudományos környezetben keletkezett, mivel a tudomány vállalkozása mélyen az együttműködésben gyökerezik.

A jelentés két utolsó üzenettel ér véget. Először is, közelebb vagyunk a kétirányú hálóhoz, mint gondolnánk. Az olyan szolgáltatások, mint a TimeDance, a QuickTopic, a Manila és a Meerkat, már most is megkönnyítik a megosztott információs terek létrehozását és használatát. Ezek nem végleges megoldások, de minden értékükre használnunk kell őket, és figyelnünk kell az újfajta együttműködési szolgáltatásokra, amelyek nap mint nap megjelennek. Csak e szolgáltatások jelenlegi formájában történő használatával deríthetjük ki közösen, hogy mivé kell fejlődniük.

Másodszor, a jövőbe vezető útiterv élesebben összpontosul. Az első generációs Web, bár rendkívül erős, számos különböző protokoll és adatformátum kínos kombinációja. Az XML körül kialakuló konszenzus, amely mind a szolgáltatások összekapcsolásának, mind a különböző típusú információk képviseletének egyetemes módja, a következő generációs Web kulcsa, amely végre megkezdheti az eredeti együttműködésen alapuló elképzelésének megvalósítását. Nincs semmi varázslatos az XML. Ez nem tündérpor. Ez önmagában nem segít nekünk együttműködni. Ami segít az üzenetek, dokumentumok, alkalmazások és szolgáltatások, amelyek mind megegyeznek egy szabványos módon képviselik az adatokat-egy olyan, amely gazdagabb, mint a vonalorientált ASCII már használt olyan régóta és jól. Ez a szabványosítás most történik. Üdvözölnünk kell, és követelnünk kell, hogy az eszközeink tiszteljék és fogadják el.

 

Vissza a főoldalra

Leave a Reply

Your email address will not be published. Required fields are marked *