Fra Ascii til Xml

Unix og software tools vandt fordi filerne var Ascii, derfor kunne værktøjerne forstå hinanden.

Idag er vores data for komplexe til Ascii tekstlinier med underforståede eller konventionelle felt-markeringer og implicitte betydninger.

Xml er vejen frem, uanset hvor lidt eller meget vi bryder os om det.

Det var nogenlunde hvor jeg endte med min keynote til EuroBSDcon2010 i Karlsruhe og jeg synes lige jeg vil delagtiggøre jer i tankerækken også.

Seneste eksempel er at mit yndlings printudlægningsprogram, EagleCad skifter til XML format.

Idag er det klassiske Unix Userland dødt, der sker ti gange flere commits til FreeBSD kernen end til userland og det der endeligt sker i userland er oftest til støtte for ændringer i kernen.

Jeg kunne godt tænke mig at Unix userland begyndte at forstå Xml filer:

grep :h3: Introduction index.html
sed :h3:/Introduction/s/Introduktion/ index.html

Der er dog nogle semantiske detaljer der skal arbejdes lidt med.

F.eks er er det ikke ret smart at fil-redirektion og Xml tags bruger mindre-end og større-end tegn[1]. Jeg brugte kolon i eksemplet ovenfor, er der en bedre løsning ?

Der er også den detalje, at inden ls(1) kan begynde at spytte Xml ud, skal vi have fundet en anvendelig model for hvorledes et terminalprogram præsenterer Xml, uden at skulle bruge et minut til at tygge sig vej igennem en Dtd osv. osv. osv.

Eller er det illusorisk at tro at vi overhovedet kan overføre Ascii fil metaforen fra Unix til Xml verdenen ?

Er filerne så komplexe at vi er tvunget til at bruge et rigtigt programmeringssprog for at manipulere dem intelligent ?

Hvordan ser Software Tools til Xml ud ?

Hvad har vi i det hele taget brug for at gøre ved Xml filer i fremtiden ?

phk

[1] Det er heller ikke smart at editoren i XOOPS bliver forvirret hvis man har disse tegn i sit blogindlæg...

Kommentarer (43)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Favrholdt

Nu er jeg jo meget pro-opensource (og når det er meningsfyldt også anti-MS), men jeg vil alligevel nævne Microsofts Windows PowerShell, der netop gør det PHK forslår i indlægget (men desværre/selvfølgelig på en MS-only måde).

http://en.wikipedia.org/wiki/Windows_PowerShell

Citat fra ovenstående link: "PowerShell, like Unix/Linux based shells, implements a pipeline. This pipeline enables the output of one cmdlet to be piped as input to another cmdlet. For example, the output of the Get-Process cmdlet can be piped to the Sort-Object process (e.g. to sort the objects by handle count) and then to the Where-Object to filter any process that has say less than 1 MB of paged memory, then finally to the Select-Object cmdlet to select just the first 10 (i.e. the 10 processes based on handle count).

While Unix/Linux systems have long employed the concept of pipelines, PowerShell differs in what is passed between stages in the pipeline. In Unix the output of one command is piped to the next stage of the pipeline typically as raw text. With PowerShell, the pipeline consists of .NET Objects. Using objects eliminates the need to parse arbitrary text output from one command to extract data since all objects export a consistent interface."

Det er så super-smart at da jeg så en demo af det sad jeg og drømte om at kunne gøre tilsvarende på Linux.

Javist vi har awk og venner, men som PHK skriver er det noget smartere at kunne referere til en attribute i stedet for at skulle tælle sig frem til "kolonne 3 adskilt af tabulator".

Jeg er sikker på at noget tilsvarende er ved at finde vej til "et opensource operativsystem nær dig". DBUS scripting er måske lidt derhenad. Og der er også nogen hits når man søger på google efter "powershell linux".

  • 0
  • 0
Peter Makholm Blogger

Jeg er helt enig i problemstillingen. Hvor ville det være dejligt hvis vores unix-værktøjskasse var stærkere end bare at kunne håndtere simple linjer af ascii-tegn. Selv CSV bliver let meget besværligt at håndtere hvis vi ikke klart holder os fra at måtte inkludere vores to seperatortegn i felterne.

Men jeg ville nu gerne lige træde et skridt tilbage. Hvad er det for et interface vi godt kunne tænke os at bruge med vores nye værktøjskasse? Og så først bagefter diskutere hvilket format der skal bruges i selve pipelinen.

For hvis vi bare vælger naivt udpeger xml som vores silver-bullet, så frygter jeg at svaret på interface-problemet bliver XSLT og XPath uden at folk egentlig overvejer om det er en god ide.

Desuden frygter jeg at vi kommer til at skulle genopfinde den dybe tallerken igen og igen hver gang vi har brug for data-strukture der er noget mere advancerede en simple træ-strukture. Lad os i det mindste sikre os at vi let kan repræsentere en DAG.

  • 0
  • 0
Henrik Schmidt

Jeg har også set Powershell demoer, og jeg kan godt lide ideen bag, men hold op, hvor skal man skrive meget, før noget fungerer.

Jeg er ikke systemadministrator, men har dog, som alle andre, brug for at grep'e, xargs'e etc. en gang imellem, men jeg løber overraskende sjældent ind i problemstillingen. Når situationen endeligt opstår, laver jeg et lille Ruby script i stedet.

Så nej tak herfra.

  • 0
  • 0
Peter Makholm Blogger

I et blogindlæg for lang tid siden skrev jeg netop op et projekt der søgte 'at genopfinde kommandolinjen'. Blandt andet ved at introducere objektbaserede pipes: http://www.version2.dk/artikel/4965

Tilsyneladende havde jeg temlig meget imod selve brugergrænsefladen, men jeg finder tilgange noget mere interessant end bare at kaste hænderne i vejret og sige 'verden vil have XML'.

Projektet er dødt nu (ser det ud til - der er en lille smule liv på http://code.google.com/p/hotwire-shell/).

  • 0
  • 0
Rene Nejsum

Jeg forstår også ønsket om noget "bedre" end CSV, men jeg håber ikke svaret er XML.

Jeg mener at JSON på alle måder (måske bortset fra markedsandele :-) er et bedre svar.

  • 0
  • 0
Jesper S. Møller

Æh, i stedet for at programmering i XML læser jeg PHK's ønske om tools á la grep og sed blot til arbejde (måske strømorienteret) på XML i stedet for flade filer.

Det mest oplagte i den sammenhæng er at nævne XPath2 og XQuery.

XPath2 er som regex for XML (altså ekstraktion af data fra XML), eks:

//td//img[width > 100]@href

Udtrækker alle "img" tags som ligger under en tabelcelle, hvor bredden er angivet til mere end 100 pixels.

Tilsvarende er XQuery sammenlignelig med 'sed' eller 'awk' for XML:

{ for $x in doc("input.xhtml")//td//img[width > 100]@href return {$x} }

Dette genererer en XML fil med disse URL'er i, og der er et fuldt udtrykssprog til at beregne og sammenstille data med.

Der er flere sådanne XQuery processorer på markedet, f.eks. Zorba og Saxon, og de kræver hverken DTD'er eller (mere relevant) XML Schema for at virke, de skal bare have XML ind.

(Men bevares, med schemainformation an man lave lidt sjovere ting, såsom "instance of" checks og den slags, men det er en længere historie.)

  • 0
  • 0
Erik Cederstrand

Jeg har brugt PowerShell en del tidligere. Idéen med en objekt-orienteret pipe er sådan set fin i teorien og "renere" end at parse tilfældigt tekst-output.

I PowerShell er tekst-outputtet bare til information for brugeren og "subject to change". Det er objekterne, som er kontrakten i PowerShell, hvor det i div. Unix-tools er tekst-outputtet (og flamewars kan opstå af de mindste ændringer i output).

Problemet er, at det er for tungt og ufleksibelt at arbejde med, i forhold til Unix shell. I praksis er der pludselig to kontrakter, objekterne og tekst-putput, og man skal konstant slå op eller printe objekt-indholdet ud for at sætte et nyt led på pipen. Det er dobbelt bogholderi. I Unix står det jeg skal bruge lige foran mig.

Samtidig er der kun et begrænset sæt objekter, som PowerShell synes er anvendelige, og hvis man vil lave sine egne scripts skal man pludselig til at definere klasser i C# før man lege med. Det er sjældent, at de data jeg behandler via min shell passer ind i forhåndsdefinerede objekttyper.

Til gengæld kan jeg godt lide den del af C# standard-biblioteket, som følger med. F.eks. er dato-beregninger ren tortur i Unix shell.

Jeg bruger min shell til quick-n-dirty opgaver i det daglige. Hvis jeg skal lave et mere formelt program er jeg hurtig til at tage f.eks. Python op af lommen. Her er XML-understøttelsen helt fin.

  • 0
  • 0
Erik Cederstrand

Idag er vores data for komplexe til Ascii tekstlinier med underforståede eller konventionelle felt-markeringer og implicitte betydninger.

Mener du det? Selvfølgelig bliver meget data på nettet præsenteret som XML, via HTML eller XML-RPC, men jeg gemmer på meget lidt XML-data. Næsten alle mine data ligger i databaser.

Xml er vejen frem, uanset hvor lidt eller meget vi bryder os om det.

Jeg råber meget højt, den dag du laver rc.d konfigurationen om til XML i FreeBSD :-) Jeg har prøvet Tomcats konfiguration. Tak, men nej tak.

Jeg er ikke så vild med dit eksempel med at greppe en HTML-fil. Hvis du vil editere, kommer du ikke udenom vim/emacs, syntax-highlighting og hvad vi ellers er blevet forvendt med de sidste 15 år. sh/bash/(z)csh/ksh... kommer aldrig til at kunne gøre det lige så godt. Hvis du vil screen-scrape, så får du hurtigt lyst til at parse headere, hente multithreaded osv. Hvis vi trænger til en fornyelse af shell'en, er det snarere standardbiblioteket, der trænger til en opgradering. F.eks. streng-operationer, datoberegninger og en nemmere udgave af "echo 2+2 | bc". Python shell'en er faktisk ike så dårlig (ducks) :-)

Når det er sagt, så er en XML parser ikke nogen dårlig ting at have ved hånden. Men hellere som stand-alone program end indbygget i sed/awx/ls/whatever. "Do one thing, and do it well".

  • 0
  • 0
Poul-Henning Kamp Blogger

Jeg kan godt forstå den akademiske længsel efter at finde noget der er bedre/kønnere/... end XML.

Unix blev en success fordi det ikke, som stort set alle andre OS på det tidspunkt, kun løste akademiske problemer, eller bogholderiopgaver.

Derfor tror jeg ikke vi har noget egentligt valg om dataformatet: Vi kan vælge XML og (for)blive relevante, eller vi kan vælge noget andet og blive irelevante.

XML er det nye lingua franca, med alle de aspekter den parallel indebærer.

Poul-Henning

  • 0
  • 0
Peter Makholm Blogger

Jeg ved godt at det kan blive opfatte meget akademisk når man begynder at bruge svære ord som grafer og DAG'er, men jeg kan love dig for at min erfaring med XML og dets problmer er baseret på praktisk arbejde.

Iøvrigt tror jeg du kommer 10 år for sent. XML var det nye lingua franca i sidste årti, ude i virkeligheden ser jeg flere og flere bevæge sig væk fra XML. I øjeblikket mest til protokol-data, men mon ikke de mere statiske filformater følger efter om en fem års tid på sammen måde som XML-brugen udviklede sig.

Men at du er ti år for sent betyder også at det virker lidt patetisk når du vil "opfinde" en repræsentation der ikke støder sammen med brugen af større/mindre end tegn, når det problem allerede er løst af XPath.

  • 0
  • 0
Jonas Finnemann Jensen

Et lille lækkert format til config filer... Som ikke kræver det store at læse...

Personlig synes jeg også XML er lidt tvivlsomt... så kan man næsten lige så godt bare gemme binært og lave et program til at skrive konfigurations filer i. (Det var måske heller ikke en dårlig idé).

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Peter,

XML var det nye lingua franca i sidste årti, ude i virkeligheden ser jeg flere og flere bevæge sig væk fra XML.

+1

Jeg vil dog sige, at på .Net-platformen har XML fået en slags renaissance i forbindelse med LINQ. Det er uhyre meget sjovere at arbejde med XML i LINQ end med tidligere tiders DOM/SAX parsere. Derfor undgår jeg ikke længere XML pr. rygmarvsautomatik - noget jeg ærligt talt havde en tendens til at gøre tidligere.

Som en anden påpegede, så bisser køerne i øjeblikket i retning af JSON (populært sagt jo blot "XML without angle brackets"). Om det er godt eller skidt tror jeg er lidt for tidligt at vurdere.

  • 0
  • 0
Peter Makholm Blogger

XPath2 er som regex for XML

Meget rammende, for jeg har det nok lidt med XPath som mange folk har det med perl regexpes.

Sålænge det er helt simplet '(a|b)*' kan alle følge med. Hvis man virkelig tager sig sammen kan mange også lige klare en en 'non-greedy quantifier' eller i værste fald en afsluttende 'look-ahead assertion'.

Men begynder vi med 'possessive quantifiers', 'negative look-behind', 'independent subexpressions', 'recursion to named subpatterns', så står de fleste af.

XPath er nok meget godt, men det er min opfattelse af 80% af mulighederne er opfundet til glæde for 0.5% af brugerne.

  • 0
  • 0
Torben Mogensen Blogger

Thrift (incubator.apache.org/thrift/static/thrift-20070401.pdf) er et system til kommunikation mellem programmer i forskellige sprog. Det definerer datastrukturer og services og sørger for at pakke datastrukturer ind og ud ved kommunikation. Jeg kunne godt forestille mig, at man kunne lave en shell, der brugte Thrift.

  • 0
  • 0
Peter Makholm Blogger

Som en anden påpegede, så bisser køerne i øjeblikket i retning af JSON (populært sagt jo blot "XML without angle brackets"). Om det er godt eller skidt tror jeg er lidt for tidligt at vurdere.

Bare at kalde JSON for "XML without angle brackets" mener jeg er en smule for simplificeret.

I XML har vi lister af tag => content.

I JSON har vi simple ordnede lister og mappings (hash lists, key/value lister, hvad du nu vil kalde det).

Jeg tror at det er vigtigt at vi begynder at tænke i den bagvedliggende objektmodel mere end det præcise on-wire format. Hvis jeg bare får JSON's objektmodel, så er jeg lidt ligegalde om det præcise on-wire format hedder JSON, BSON (Binary JSON, brugt af MongoDB) eller MessagePack (http://msgpack.org - med totalt bogus benchmarks imho).

  • 0
  • 0
Anonym

Jo, jeg har efterhåndet accepteret, at jeg måske er den eneste overlevende dinusaur fra fortiden, men prøv lige at tænke på XML/Schema og 'gammeldags' COBOL.

Enhver, der har rodet med EDB kender til en fundamental problemstilling - postnummer og by.

PBS,PTG og bankerne opererede med 4*34 tegn til en adresse, og man kan opløse postnummer(DK) til 4 tegn + whitespace + 28 tegn - sådan har det altid været.

Antag følgende COBOL definition: .... 05 postby PIC X(34). 05 rbostby REDEFINES postby. 10 post PIC X(4) eller PIC 9(4). 10 FILLER PIC X, 10 by PIC X(28). .... Denne konstruktion implicerer een blank, eller man kan definere by som X(29).

I COBOL har man fri bevægelighed mellem X34 og underdefinitionen, men i XML har man et problem med REDEFINES..

Men data kunne se således ud: 4711 Andeby Og 'schemaet' eller den analoge COBOL definition kan bruges til: postby = 4711 Andeby eller: post = 4711 by = Andeby

Incitamentet for XML er 'human readability, uagtet at en PIC 9(8)V,9(2) er perfekt 'human readable'.

Men 'gammel vin på nye flasker' styrer.......

  • 0
  • 0
Poul-Henning Kamp Blogger

Men tror du vi kan sælge JSON til EUrokraterne og ITST ?

Nu har de kæmpet for XML i et årti, den indsats lægger de jo ikke lige på hylden...

Og glem ikke at XML er en tussegammel international standard der er skrevet ind alle mulige steder...

Poul-Henning

  • 0
  • 0
Anonym

Nu har de kæmpet for XML i et årti, den indsats lægger de jo ikke lige på hylden...

Det er nu ikke et årti - PHK, men nærmere 7-8 år.

Jeg blev hyret til at være med til at starte/definere 'XML-projektet' men det var VTU/ITST i samdrægtighed.

(ITST er et 'datterselskab' af VTU).

Mit engagement strækkede sig over ca. 1½år, og jeg kan fortælle alenlange historier om 'linseluse', 'monomumentskabelse' o.m.m. men da jeg har tavshedspligt, så må det blive engang - if ever- og som man siger 'under 4 eyes'.

  • 0
  • 0
Anonym

@Kim

Hvad mener du med 'mit' program?

Jeg (forsøger at) beskriver verden, som den så ud anno '83, hvor vi (DK) vitterlig var verdens førende nation, da vi indførte 'papirløse obligationer'.

Tror du jeg er COBOL-elsker? Næh, men det har nogle styrker, som ikke eksisterer i diverse 'sprog'.

Et gammelkendt problem er 'rounding errors', da de fleste sprog kun forholder sig til floating point, som på ingen måde er velegnet til finans, eller økonomiske systemer.

Og uanset hvad du mener, så tror jeg stadig, at det er finans og økonomiske systemer, der 'driver verden'.

Hvor mange virksomheder kender du, der IKKE har et økonomisystem? - eller har brug for samme.

  • 0
  • 0
Anonym

Nu inddrog jeg COBOL, hvilket i sagens natur får folk til at fare i flint.

Tanken var ikke at promovere COBOL, men at gøre opmærksom på forskelle, eller ligheder, mellem XML/SChema og tilsvarende 'COBOL definitioner'.

Men bare rolig, for de systemer jeg lavede i forbindelse med 'papirløse obligationer' var på HP-grej, og i HP's (proprietære) 'Business Basic.

Interoperabilitet var dog intet problem, da alle data var defineret som 'human readable' ascii, uagtet båndbreddeforbrug (jfr. ovenstående).

Prisen for 9.600 baud synkron forbindelse ville nok få enhver pacemaker til at sige 'tilt' i dagens DK.

Interoperabilitet var dog ikke 100% gnidningsløst, da 'vi' (HP-grej) opererede med Roman-8, og IBM opererede med EBCDIC, og disse karaktersæt var jo ikke ligefrem kompatible ;-)

Men da det centraale (VP¤) system var så primitivt, så det kun opererede med store bogstaver, var 'kovnerteringsalgoritmen' begrænset til ÆØÅ (aka #@$) IIRC..

  • 0
  • 0
Esben Nielsen

On topic: Jeg foretrækker bl.a. make fremfor ant fordi XML er af h**** til i en teksteditor. Ja, man skal passe på space og tabs i make. Men det lærer man nu hurtigt...

Offtopic (ant vs. make generelt): Når man først har prøvet, at få ant til at lave noget nogenlunde intelligent, går man tilbage til make....

For mig virker ant, som noget nogle har opfundet fordi man var træt af make, xml var "smart" og man gerne ville kunne bygge på Windows. Resultatet er et lille, primitivt byggesystem, som kun virker til Java. Hvis man droppede kravet om at ville bygge på Windows, kunne man skrive det i shell scripts (som man så kunne køre under Cygwin).

Medmindre der er sket meget fra version 1.6 foretrækker jeg make.

  • 0
  • 0
Peter Makholm Blogger

Jeg har allerede en xml_grep kommando. Hvis jeg henter denne webside og maserer den lidt med recode, htmltidy og en lille smule perl, så kan jeg udføre følgende kommando:

$ xml_grep --pretty_print --nowrap --root "//div[@class = 'subject']" fra-ascii-til-xml.xhtml

og får så en "pæn" liste af links til alle debatoverskrifterne.

Jeg har lagt indput på http://hacking.dk/files/xmlgrep/fra-ascii-til-xml.xhtml og output på http://hacking.dk/files/xmlgrep/output.txt

Det er tilsyneladende et værktøj der følger med et at XML modulerne i perl: http://search.cpan.org/perldoc?xml_grep

  • 0
  • 0
Fini Alring

Både XML og JSON har deres styrker, men jeg ser stadig XML som det overordnede format til struktureret data.

XML har XPath, XML Schema (bedre end DTD!) samt en masse XML baserede standarder såsom RFD (RSS etc.), Atom etc..

Derudover har vi OpenDocument, XHTML m.v.

Jeg har endnu ikke set værktøjer til at validere JSON data på samme måde som XML Schema kan gøre det for XML, eller grave ned i JSON data på samme måde som XPath og XQuery.

Jeg har brugt XML i årevis og er også glad for JSON, men jeg kan ikke se at vi skal have f.eks dokument standarder i JSON format, omend det altid er rart når f.eks ens "XML Object" kan outputte en JSON streng.

  • 0
  • 0
Søren Peter Nielsen

@Poul-Henning,

Nu arbejder jeg for ITST så jeg vil blot gøre dig opmærksom på at vi - baseret på feedback fra rigtige udviklere - for ikke så lang tid siden har løsnet på kravene omkring OIOXML http://bit.ly/ahAbdC

Yderligere vil jeg henlede din opmærksomhed vores publikation "OIOREST i praksis" http://bit.ly/dzVz7p hvor vi skriver:

"Det står således frit for at anvende andre formater end XML, men hvis man har brug for at udtrykke værdier og samhørighed (attributter og referencer), vil det være oplagt at anvende det, der allerede er konsensus om frem for at opfinde noget nyt og derved introducere fejlmuligheder i fortolkningen heraf - og her er XML et godt valg. Og som sagt så er det vigtigt at holde det simpelt og umiddelbart overskueligt."

Vi er ikke religiøse omkring XML og kigger også på andre sprog/notationer, herunder JSON. Skulle du få lyst til at kigge mere på OIOREST-arbejdet på http://digitaliser.dk/group/19975 vil du også finde kode der arbejder med JSON.

/Søren P

  • 0
  • 0
Rasmus Kaae

XML er ikke løsningen på alle problemer. Jeg synes at folk efterhånden misbruger XML i en lang række situationer hvor det slet ikke er nødvendigt. I de fleste tilfælde kan f.eks. CSV eller tilsvarende formater bruges langt mere effektivt end det alt omfavnende XML format.

Som du selv nævner, så vil det være uudholdeligt med en omgang XSLT for hver eneste kommando i terminalen.

  • 0
  • 0
Carsten Sonne

Genialiteten i XML er den dikterede skematiske (schema) og sematiske (semantic) struktur. At XML er et såkaldt 'human readable language' er en sideeffekt der ikke altid er positiv. Den forudbestemte træstruktur dækker lige præcis den del af et format som ikke behøves at varierer.

XML har sine styrker og svagheder: 1) Metadata i konfigurationsfiler kan hjælpe til forståelse og gøre det nemmere og hurtigere at tilpasse konfigurationen. Samtidig sikres fælles semantik at konfigurationsfiler kan favne over vidt forskellige konfigurationer fra vidt forskellige leverandørere .Net er et godt eksempel herpå. 2) Lagring af data er knap så oplagt. Der er lav entropi i XML grundet dets 'human readable language' natur. Resultatet er ofte uforholdsmæssige store filer. Samtidig kan den dikterede træstruktur være en ulempe. 3) Udveksling af data med henblik på interoperabilitet kan med fordel sikres med XML. SOAP er et godt eksempel herpå. Som med lagring af data giver den lave entropi dog ofte en del begrænsninger.

XML kan med fordel benyttes til konfigurationsfiler. På den anden side kan rene ASCII filer langt hen af vejen det samme som XML uden at tilføre ulemperne ved XML. Med henblik på lagring og specielt på sikring af interoperabilitet er det store problem den lave entropi eller 'overheadet' om man vil.

W3C arbejder på EXI, et binært XML format. EXI kan vise sig at lette kraftigt på ulemperne ved XML ift. lagring og dataudvekling samtidig med stadig at sikre interoperabilitet på en optimal måde. Den lave entropi vil slå XML ihjel før eller siden. Genialiteten i en dikteret skematiske struktur vil dog helt sikker overleve i den ene eller anden form.

XML understøttelse må ind til videre betragtes som afgørende i relation til udbredelsen af software på f.eks. BDS. Efterfølgende vil dele af kodebasen kunne genbruges til understøttelse af EXI eller hvad der nu bliver fremtiden generiske skematiske og semantiske struktur.

  • 0
  • 0
Anonym

Nu arbejder jeg for ITST så jeg vil blot gøre dig opmærksom på at vi - baseret på feedback fra rigtige udviklere - for ikke så lang tid siden har løsnet på kravene omkring OIOXML http...

Yderligere vil jeg henlede din opmærksomhed vores publikation "OIOREST i praksis"

Hvis du arbejder for ITST, så burde du også have adgang til fordums dokumenter og beslutningsgrundlag.

Dit navn dukker ikke op på hjernehinden i forbindelse med (OIO)XML projektets fødsel.

Men man skal kende historien for at kunde nutiden, og hvis du spoler tiden tilbage til 'dengang' vil du observere, at: 1) SOAP var en etableret standard. 2) Sun skulle holdes udenfor, da WS* standarderne var et samarbejde mellem MS og IBM 3) REST var noget man snakkede om, men ikke implementeret i diverse webservere, hvorimod diverse 'SOAP værktøjer' var udbredt.

Prøv at forholde dig til 'vores' definition af åbne standarder: 1) Den skal være frit tilgængeligt. 2) Den skal omkostningsfrit kunne implementeres. 3) Ikke mindst - og vigtigst: Den skal understøttes af mindst 3 (betydende) leverandører på markedet.

Desværre endte det med, at 'man' blev MS fokuserede, uagtet der var bedre[1] aktører på markedet.

[1] Min personlige vurdering, men udbud afgøres på demokratisk vis, hvor 'flertallet' vinder.

  • 0
  • 0
Søren Peter Nielsen

Dit navn dukker ikke op på hjernehinden i forbindelse med (OIO)XML projektets fødsel.

Korrekt - jeg har "kun" været hos ITST siden 2004 - og dit navn dukker heller ikke op på min hjernehinde ;-)

Jeg forholdt mig egentlig ikke til om der blev truffet rigtige eller forkerte beslutninger dengang for lang tid siden.

Hvis du vil have en pointe er den at vi må erkende at tiden ikke står stille udenom det univers som hver af os nu engang interesserer os for og engagerer os i. I den virkelige verden er der ikke nogen "final end state". Derfor er det vigtig hele tiden at forholde sig til hvordan omverdenen påvirker os og justerer tilsvarende. Det har vi som nævnt gjort med OIOXML for nylig.

/Søren P

  • 0
  • 0
Anonym

Hvis du vil have en pointe er den at vi må erkende at tiden ikke står stille udenom det univers som hver af os nu engang interesserer os for og engagerer os i. I den virkelige verden er der ikke nogen "final end state".

Jeg har ikke brug for nogen pointe, og jeg er glad for din udmelding om 'universet'.

Hvis du vil gøre noget gavn i stedet for at 'skabe monomenter', så skil tingene ad i de enkelte bestanddele.

Du/I må selv tænke videre, men eks: SOAP er ikke bundet til HTTP. REST er en HTTP protokol, og har intet med indhold at gøre (XML/ASCII/Ansi...) [b]Reliability[/b] er et must inden for kritiske transaktioner, hvor HTTP nok er den værst tænkelige løsning (stateless).

I ovenstående indlæg har jeg vistnok blandet to projekter sammen (DOIP og ISB), men det er nok begyndende Altz.... (shit jeg kan ikke huske hvad det hedder).

Jeg kunne skrive alenlange forklaringer, men tænk på fordums tider, hvor man forsøgte at skille tingene ad (OSI modellen) for derefter af lave en spaghetti sammenblandning (aka web services), som i bund og grund kun er en enkelt afart af OSI modellen.

(Sammenblanding af 'webservices',HTTP,SOAP osv..)

  • 0
  • 0
Stephen Aaskov

REST er en HTTP protokol, og har intet med indhold at gøre (XML/ASCII/Ansi...)

Njaa, REST er mere et paradigme der taler om at man skal lave ressource orienterede services. Disse ressourcer transporterer man så over HTTP, og mapper HTTP primitiver til handlinger på ressourcerne.

REST har vel så ret meget med indhold at gøre, og er ikke nogen protokol.

  • 0
  • 0
Anonym

Njaa, REST er mere et paradigme der taler om at man skal lave ressource orienterede services.

Jeg forholder mig til, at man 'genindfører' 'paradigmerne' fra de utallige 4GL sprog, hvor man snakker GET/PUT/UPDATE/DELETE.

Disse er direktiver, og er uafhængig af indhold.

Disse 'direktiver' findes også ældre kommunikations 'protokoller', og er netop ikke bundet til 'bæremediet'.

Der er intet til hinder for, at man kan transmittere SOAP over SMTP/SNA eller lign., ej heller noget til hinder for man kan transmittere disse direktiver (samt indhold) over et hvilketsomhelst (elektronisk) medie.

Glem bindinger til HTTP, som nok er det dårligste (men billigste) 'medie' jfr. 'burhønseeffekten'.

Men 'burhønseeffekten' er forbrugervalgt, så man kan ikke klandre leverandørerne.

  • 0
  • 0
Kim Dalsgaard

@stig

Der er en god intro til REST her

http://www.infoq.com/articles/rest-introduction

Og så er det vigtigt at huske at REST er en applikationsprotokol og IKKE en transportprotokol som SOAP- folkene gjorde den til!

Hvad angår lagdeling så er REST bygget til dette - se evt. 5.1.6 i Roy Fielding PhD. afhandling

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

  • 0
  • 0
Log ind eller Opret konto for at kommentere