OZ 2004/2

M 69 ORGANIZACIJA ZNANJA 2004, LETN. 9, ZV. 2 POROČILO • SVG 1.2 omejuje uporabo kode javascript glede na specifikacijo SVG 1.1 [62]; • definiran je nov jezik sXBL [81] za prezentacijo po- ljubnih dokumentov XML v formatu SVG (transfor- macije, definirane s tem jezikom, so enostavnejše od transformacij XSLT in obojestranske – z modifikacijo končnega dokumenta SVG lahko dobimo originalni dokument XML); • izboljšanje SVG DOM-a z novimi možnostmi, kot so na primer dostop do lastnosti slik in celo do pikslov ali podpora mrežam. UBL, SOAP, REST Konzorcij OASIS je razvil specifikacijo UBL 1.0 [82] za definiranje standardnih poslovnih dokumentov v formatu XML. Specifikacija vsebuje sheme XML za osem vrst standardnih poslovnih dokumentov: Order , Order Chan- ge , Order Response , Order Response Simple , Order Can- cellation , Despatch Advice , Receipt Advice in Invoice . Za te dokumente je Ken Holman razvil predloge za vizuali- zacijo na spletu in v formatu PDF s specifikacijama XSLT in XSL-FO [83] in jih tudi predstavil v prispevku Writing Formatting Specifications for XML Documents . Dizajn jezika UBL je prirejen uporabi v standardnih po- slovnih ogrodjih, kot je ebXML [84]. Pred dvema letoma je imel ebXML celo samostojno enodnevno konferenco znotraj konference XML Europe 2002, lani je bil za njega rezerviran en sklop, letos pa se je o ebXML govorilo le v okviru drugih sklopov, na primer v okviru spletnih stori- tev. Jeff Barr iz podjetja Amazon.com [85] je v uvodnem predavanju Driving Innovation With Web Services at Amazon.com predstavil strategijo in realizacijo spletnih storitev, ki jih uporabljajo pri poslovanju podjetja z nji- hovimi partnerji in uporabniki. Njihove spletne storitve podpira dosti več servisov, kot so nakup in prodaja. Za- radi tega je pomemben dizajn vmesnikov za sodelovanje med partnerji. 80 % zahtev dobijo preko spletnih storitev REST ( Representational State Transfer ) [86], čeprav ima- jo iste storitve uvedene tudi preko protokola SOAP [87]. REST ni standard, temveč predstavlja arhitekturni stil mrežnih sistemov in svetovnega spleta, uporablja pa standarde, kot so HTTP, URL, tipe MIMA, XML/HTML/ GIF/JPEG in druge standarde za predstavitev virov. Ar- hitektura REST je usmerjena k virom ( resource-oriented ) za razliko od arhitekture SOAP, ki je usmerjen k servisom ( service-oriented ). Upoštevanje principov arhitekture REST zagotavlja dobro delovanje naših servisov v kon- tekstu svetovnega spleta. Paul Prescod je v prispevku Take REST: An Analysis of Two REST APIS primerjal dve izvedbi spletnih storitev REST: Amazon.com in Atom [88]. Amazon.com preko spletnih storitev odpira svoj informacijski sistem za partnerje in kupce in predstavlja center tako razširjenega podjetja. Identifikatorji, ki se up- orabljajo v teh storitvah, so praktično identifikatorji ASIN iz Amazonove podatkovne baze. Nasproti takemu cen- traliziranemu sistemu identifikacije virov, Atom uporablja URI-je, ki so po definiciji univerzalni in ne potrebujejo neke centralne administracije. Status TEHNOLOGIJE XML Po zaključnih beseda Edda Dumbilla je status XML-ja po šestih letih od nastanka specifikacije XML 1.0 dober. XML je postal bistvena tehnologija na mnogih področjih in podprta v vseh glavnih programskih jezikih. Sedaj ni več vprašanje “Zakaj uporabiti XML?”, pač pa “Zakaj ne?”. Mnogi razvijalci se zavedajo pomembnosti metapo- datkov in to ne samo v klasičnem smislu, za opis velikih podatkovnih struktur, pač pa tudi za opis podatkov, ki jih sami vsakodnevno vedno več “proizvajamo” in med seboj izmenjujemo ali skladiščimo: e-poštni naslovi, foto- grafije, glasba, film itd. Zaradi tega tudi proizvajalci ope- racijskih sistemov na najnižjem nivoju posegajo za pred- nostmi tehnologije XML pri skladiščenju in upravljanju z metapodatki. Posledično imamo dosti razvitih orodij, ki podpirajo tehnologije, kot so Topic Maps ali shema W3C XML. Na žalost to ne rešuje glavnega problema: Katero shemo ali ontologijo uporabiti v katerem primeru? Težko je pričakovati, da bo ena globalna ontologija ali shema konsistentno podprla vse naše zahteve in pri tem še omo- gočila interoperabilnost. Verjetnejša rešitev sedaj je v definiranju nekaj strukturiranih metapodatkov, ki ustreza- jo strukturi in namenu naših podatkov. Tu pa se pojavlja problem dizajna ustreznega formata XML. Problem je tudi, kako uskladiti vse te dokumente XML, predloge XSLT, sheme in podobne vire XML, da vse skupaj ne bo predstavljalo samo ene zmešnjave ukazov in atributov. Vzpodbudno je, da so se znova začele aktivnosti na naj- nižjem nivoju XML-ja, ki lahko pomagajo odpraviti ali ublažiti takšne probleme. Te aktivnosti mogoče niso tako “glamurozne” kot aktivnosti okrog spletnih storitev ali ebXML-ja, preprečujejo pa večkratno reševanje istega problema na višjih nivojih, ki lahko pripelje do slabše interoperabilnosti. V glavnem se te aktivnosti odvijajo v okviru konzorcija W3C, čeprav se delovne skupine organizirajo tudi izven njega. Primer uspešnega delovanja delovne skupine znotraj konzorcija OASIS je shema-je- zik RELAX NG, ki predstavlja resno alternativo jeziku W3C XML Schema. Zaradi svoje enostavnosti glede na shemo W3C XML ga uporabljajo tudi znotraj nekih delo- vnih skupin pri W3C in tudi pri Microsoftu za interno predstavitev struktur celo takrat, ko je končni proizvod neka shema W3C XML. Slaba stran razvijanja osnovnih specifikacij XML izven delovnih skupin konzorcija W3C je nekoordiniranost s strategijo razvoja specifikacij XML, ki je del arhitekture svetovnega spleta, kakor jo je določil