XML-forstoppelse

Jeg er også et krigsbarn.

Men vi har da ikke haft en krig i nyere tid, bortset lige fra Irak krigen? Og så ung er ham fidusen med sablen vist heller ikke, tænker du måske. Men jo, det har vi. For snart 28 år siden da jeg fysisk set var et barn endnu, rasede Endiankrigen i it-branchen.

Denne bitre konflikt lånte sit navn fra Jonathan Swifts "Gullivers Rejser" hvor Lilleputterne kriges mod Blefuscuianerne over det stærkt eksistentielle spørgsmål: I hvilken ende bør man åbne et æg? Den brede ende (big endian) eller den spidse (little endian).

Indenfor it handlede krigen dog om fortolkningen af bits, der serialiseres over en transportkanal. Hvis hvert tegn f.eks. repræsenteres af 16-bit kan tallet 0x0A0B serialiseres som 0x0A,0x0B (big endian) eller 0x0B,0X0A (little endian) afhængig af hvad man er til.
 
I min erindring står bla. Motorola som de kætterske Bleufuscianere hvis big-endian byteordning var langt lettere at læse med en hexeditor, mens Intel tager pladsen som Lilleputterne.

Endiankrigen er fra en tid, hvor hukommelsen var knap, lagerpladsen lille og hvor det var en dyd at vende hver en bit før den blev brugt. Sådan er det jo i krigstider og det præger krigens børn.

I dag er konflikten slut og man er blevet tilstrækkeligt enige om standarder for serialisering - forskellene i "endian" til trods - til at det er blevet praktisk at sende data på tværs af platforme.

SOA med OIOXML

For tiden er jeg involveret i et større SOA projekt, der med webservices søger at integrere en række it-systemer på tværs af organisatoriske grænser. Projektet anvender meget fornuftigt IT- og Telestyrelsens OIOXML som grundlag for hvordan servicekontrakten udformes og kører UTF-8 som tegnformat uden endianproblemer.

OIOXML-initiativet sigter på at få skabt en række fælles datamodeller. I kernen findes de generelle XML skemaer, der potentielt kan bruges på tværs af fagdomæner, adressoplysninger, kommunekoder, etc. og udenom findes de domænespecifikke, patient, kapitalindkomst, mm. Håbet er at man med tiden får skabt et stort modelbibliotek i form af ISB'en, der er consensusskabende for hvordan information udveksles.

Et værdigt mål!

Misforstå mig derfor ikke: jeg er stor tilhænger af standarder og bakker bestemt op om OIOXML, men der er en hage ved det, der piner krigsbarnet i mig.

Det fylder helt vildt meget!

Navgivnings- og Designreglerne for OIOXML (NDR 3.0) siger nemlig bla. at det ikke er tilladt at bruge forkortelser. Det betyder f.eks. at en ellers alment anerkendt term som "CPR" bliver til "PersonCivilRegistrationIdentifier".

Snydepakker

Når XML på denne måde udelukkende optimeres ud fra navngivningskonventioner uden skelen til størrelsen bliver det lidt som med de snydepakker vi alle hader at finde under juletræet. De er voldsomt store og har fint bånd omkring, men bag alle lagene af indpakning og tape indeholder de skuffende lidt.

Hvis den slags pakker sendes med posten fylder det op i lastrummet, koster ekstra og sender flere postbiler på vejene i den proppede myldretrafik. I SOA-projektet betyder de store pakker at flere af parterne formodentlig må opgradere linjekapaciteten for med sikkerhed at kunne opfylde servicemålene.

Og selvfølgelig kan vi lukke luften ud af pakkerne med alskens komprimering, men så skal de jo pustes op igen inden de afleveres. Vi kan da også lave vores egne typer, men så ryger ideen med OIOXML på gulvet med et hult drøn.

Suk, sagde krigsbarnet, hvor kunne vi dog udveksle meget mere data over det kobber vi har, hvis alting ikke skulle repræsenteres som tekst.

Glædelig jul.

Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jens Madsen

Jeg tror der er sket en skift i typen der ønsker at være programmør. For mange år siden, vil programmøren have sparet enhver overflødig bit bort, meddens de i dag bruger masser af resourcer på at beskrive det samme igen og igen, og samtidigt kalder det kompakt. Det samme er sket, indenfor algorithmer, hvor programmører i dag arbejder på bedre kompleksitet (hvilket de altid forstår som større kompleksitet og større store O funktion). Programmer, har ofte fået algorithmer udskiftet med nye, der har dårligere store O funktion, og langt dårligere forbrug af ram, og dette kaldes af programmørerne en gevindst og forbedring. Resultatet er, at computerne bruger mere og mere strøm, og en opgave der på nutidens computere vil kunne have kørt et år på en AA batteri, kan i dag kun køre to minutter. Antallet af overflødige indstruktioner der udføres er enormt.

Det har aldrig været en udfordring at gøre tingene stort. Det kan enhver. Men, at opnå det minimale er en udfordring, som er enorm svær. Ofte, så ser det minimale dog nemt ud, og det er nemt at overskue. Og derfor leder det til færre fejl. Og den typiske kommentar som det minimale får med på vejen er, at det er så nemt at enhver kan finde ud af det. Men ingen kunne, før de fik resultatet foræret.

  • 0
  • 0
Troels Liebe Bentsen

Jeg sidder selv i en ligende problemstilling, jeg er i gang med at lave et SOAP interface til noget kode jeg har skrevet. Og faldt også selv i fælden og gik i gang med at optimere på tags, data strukturer og om jeg skulle understøtte pipelining af HTTP request så jeg kunne spare et par TCP handshake.

Men efter et par timer kom jeg heldigvis på bedre tanker og begyndte at kigge på det på en mere pragmatiske side. For det er jo bloated lige meget hvor meget jeg så end optimere. Bare tag et hurtigt kig på hvor mange liner du skal bruger for at beskrive en simple funktion i et WSDL dokument og så kan man hurtigt drage den konklution at det aldrig bliver så simpelt og lækket som man godt kunne ønske sig.

For hvis det skulle være effektivt og småt på linje ville en custom binær protokol helt sikkert alt tid være end bedre ide. Men er det nemmer at bruge og arbejde med? Og er de 30 ekstra milisekunder XML fortolkeren skal bruge på at opbyggen den interne repræsentation virkeligt den lille linje besparelse værd? Og når man kaster komprimering ind over(som er standard i stort set alle webservere i dag) bliver den forskel jo endnu mindre.

Så hvor så ikke bare købe noget mere jern, slå komprimering på og lade værd med at spilde flere konsulent timer på at optimere på noget der alligevel ikke gøre det store fra eller til.

  • 0
  • 0
Dennis Krøger

Pjat, man udskifter en algoritme med en større/langsommere uden grund.

Det er en simpel afvejning mellem f.eks. en optimeret, men uigennemskuelig og ikke validerbar binær prototol, og en WS-* protokol der er selvbeskrivende og validerbar.

I andre tilfælde kan det være mellem udviklingstid og optimering, eller mellem fleksibilitet og optimering.

Den binære protokol er ofte den dårligste løsning, med mindre man virkelig har BRUG FOR den optimale ydeevne. Her kunne visse spil, eller kontrol der kræver lynreaktioner være eksempler.

  • 0
  • 0
Dennis Krøger

Bloat er oftest en betegnelse for ting der unødigt er større, det er jeg ikke helt enig i er tilfældet ret ofte.

Eller er jeg enig, og vil jeg tilføje at WSDL filen jo kun bliver læst en gang per klient per... Well, dag eller uge eller whatever alt efter caching indstillinger.

En ting der dog skal siges, er at man helst skal undgå alt for meget urn: pjat i selve SOAP kaldene, de kan i visse tilfælde nemt både fordoble og tredoble størrelserne. Men det er så hudt jeg visker op til SOAP versionen og SOAP stakken, men ens WSDL kan indvirke.

  • 0
  • 0
Jens Madsen

XML strukturen er fin, hvor der er en samling data der skal placeres i et hiraki. Men til mange formål, foretrækker jeg kommasepareret eller tabulator separeret protokoller, fordi de er nemmere at læse, og de kan simpelt hentes ind i en tekstbehandling eller regneark og behandles.

Netop protokollernes egnethed til at blive vist i et 3.parts neutralt tool, såsom regneark og tekstbehandling er væsentligt når en god protokol skal vælges. Hvis protokollen kan udvikles, således de endog samarbejder med disse tools, kan et samarbejde med et regneark være guld værd. Der kan lægges formler ind, automatisk udskiftes datoer og mange andre ting.

XML er fint, når det ønskes et foldeud træ, til at vise tingene, men det halter bagefter i forhold til kommasepareret, ved visning i tekstbehandling, på udskriftsform, og lader sig ikke normalt importere og vise i et regneark.

Som jeg ser det, er det vigtigt når man vælger sit format, at sikre det er overskueligt, og ikke indeholder mange felter der skal rettes flere steder. Det er bedst, hvis formatet er editerbart i 3. parts tools, at det kan udskrives, og at det er forståeligt i læseligt form, samt søgbart med tools som grep og wingrep (ikke binær form).

Grunden til, at jeg har stor skepsis med hensyn til XML er at dette er blevet et modefænomen. Ofte har man taget ganske velfungerende kommaseparerede formater, eller tabulatorseparerede formater, og lavet disse om til XML format - med resultatet at der er manglende gennemskuelighed i datafilerne, at de sjældent kan læses i teksteditor, mange regneark vil ikke læse data, og endeligt fylder pladsen ekstremt i forhold til det tabulatorbaserede format. Da dataene endvidere stod pænt og forståeligt, som indtastet, i det tabulatorbaserede format, og kunne genkendes til at være indtastet korrekt, var dette en god verifikationsmulighed som forsvandt ved overgang til XML.

At gemme data binært, er ikke nødvendigvis mere optimalt, end at gemme i tekst form. Hvis data pakkes med et godt tool, vil de oftest fylde mindre i tekst form end i binært format. Det binære format er mere "fastlåst" end et pakket format.

Propper du langt mere overflødigt information i filerne, og sætter tags på, som intet andet betyder end de giver versionskonfligter og problem med editerbarheden direkte i XML filerne, så vil disse tags oftest give problemer med fremtidens versioner og programmørernes forståelse af disse, samt også fylde når de gemmes i komprimeret format. Hvis XML træet giver en god repræsentation af data, er XML godt.

XML's største problem, er dets fleksibilitet. Det tillader, at alt gemmes ukritisk. Nogle kan finde på, at gemme computerens interne tilstand sammen med datafiler, og udover at virke kritisk, giver det ofte anledning til problem ved editering. Data bør helst gemmes som data, og det skal fungere uden at computerens interne tilstand følger data.

  • 0
  • 0
Henrik Liliendahl Sørensen

Jeg er også opvokset med filnavne på 8 karakterer - og ikke hele første afsnit af tekstdokumentet.

Engang oplevede jeg en kunde som syntes at prisen på OIS data var utrolig billig - nogle håndører pr. MB. Det var lige indtil der kom data i XML.

Den største fordel ved XML er vel, at det er en standard. Og anvendeligheden af standarder stiger med udbredelsen.

PS: Tænk at 'OIOXML NDR 3.0' ikke tillader forkortelser.

  • 0
  • 0
Julian Hollingbery

To ting som XML vinder med i forhold til binære eller kompakte tekstformater: De er (relativt) nemt at debugge, eftersom det er humanlæsbart, og det er (relativt) fejltolerant. Dermed er det knaldgodt at bruge mens der endnu udvikles på ens system, men når man er færdig, burde man IMHO køre noget automatik for at gøre kommunikationen så kompakt som muligt. Men OK - hvornår har du sidst hørt om et IT-system som var "færdigt"...

  • 0
  • 0
Kåre Kjelstrøm

Det er måske rigtigt lige indtil man begynder at more sig med de mere subtile specifikationer som XMLSignature og WS-Encryption.

Disse specifikationer lider af helt særskilte problemstillinger fordi man nu begynder at betragte den ellers så relativt whitespaceignorante XML som en stream af bits der død og pine skal være identisk mellem klient og server for at signering/validering og kryptering/dekryptering kan fungere.

Så får man pludselig brug for algoritmer for at fjerne whitespace og formattere XML ens (skriver man f.eks. "Ø" eller Ø ?)

Emnet er faktisk så omfattende at det næsten fortjener sit eget blogindlæg :-)

  • 0
  • 0
Mikkel Hippe Brun

Super indlæg! Spørgsmålet om hvor meget XML fylder, og hvilke konsekvenser det har for processeringen har fyldt meget gennem årene.

Jeg var hovedforfatter til NDR 1.0 og har selv været med til at lave reglen om at man ikke må benytte forkortelser. Jeg kan sagtens se, at denne regel kan give anledning til mange grinagtige navne. For en dansker er "CPR" forkortelsen almen kendt, men det er den ikke ude i den ikke i fx. Indien. Den stakkels indiske programmør har ikke et begreb skabt om hvordan han skal opfatte "CPRid". Hvilken semantik knytter der sig til dette tag? Han ved at det er et ID for en eller anden TBF. Hvis han er heldig, er der udarbejdet en dokumentation for de forskellige tags, og hvis han er uheldig er dokumentationen på dansk.

Prøv i øvrigt at se de regler der er om brug af danske og engelske elementnavne i NDR 3.0. Vi gør det ikke lettere at ’out source’ vores systemer hvis vi benytter danske elementnavne. Det er en anden diskussion som jeg godt kunne tænke mig at få op her på Version2.

Tilbage til diskussionen om de potentielt store datamængder som vi får med XML. Det er ikke nogen hemmelighed at jeg er stor fan af XML. Jeg har også prøvet at arbejde med meget store XML-filer i fx OmniMark. Det er min opfattelse at man med de rigtige værktøjer meget sjældent har udfordringer med de lange elementnavne. Men der hersker ingen tvivl om at hvis man ikke tænker sig om, så kan en applikation blive sløvet gevaldigt ned. Vi har eksempler på elektroniske regninger med flere hundrede tusinde varelinjer på op til 42 MB. I sig selv ikke nogen stor datamængde, men det kan godt være et problem for et fakturahåndteringssystem, som skal opbygge en DOM repræsentation inden det kan behandle dokumentet.

Udfordringerne melder sig også i relation til web services via http. Her ligger grænsen ligeledes omkring de 50 MB og i de sammenhænge er det naturligvis ikke ligegyldigt hvor meget et element fylder.

I stedet for at komme med svarene her vil jeg gerne benytte anledningen til at invitere alle interesserede til en brainstorm /workshop omkring indholdet til en kommende web service profil for "store datamængder". Workshoppen forventes afviklet i slutningen af januar. Interesserede kan sende en mail til mhb@itst.dk.

Mikkel Hippe Brun
Center for Serviceorienteret Infrastruktur
IT- og Telestyrelsen

  • 0
  • 0
Kåre Kjelstrøm

Hej Mikkel,

Tak og fint tilbagespil :-)

Mht. forkortelser så kommer vi alligevel ikke udenom at begreber løsrevet fra en sammenhæng kræver et par ekstra ord med på vejen fordi det talte sprog er jo netop kontekstsensitivt som i "the man opened his chest", hvilket kan være to meget forskellige ting :-).

Modeller er jo alligevel netop det, en repræsentation af elementer i et domæne og dermed kontekstsensitive. Derfor skal udenforstående alligevel sætte sig ind i begrebernes betydning i en given situation og kan vel godt lære hvad CPR står for når vi snakker personoplysninger? Ad samme tangent står PLO for Praktiserende Lægers Organisation når konteksten er sundhedsvæsenet, mens det har en lidt anden betydning i nærheden af Palæstina ...

Godt initiativ med workshoppen - Jeg deltager gerne!

/Kåre

  • 0
  • 0
Peter Nørregaard Blogger

Vi har også et par bitvendere i min organisation som synes at XML (fx OIOXML) er spild af bits. Men de har ikke rigtigt forstået budskabet: At pladsforbruget er underordnet hensynet til en forståelig kommunikation på et tilpas højt abstraktionsniveau.

Men XML tillader også en elegant lagdeling: Udpakket når der er behov for det på applikationslaget og effektivt komprimeret når der er behov for det på netværkslaget eller på storage.

Et eksempel: Microsofts OOXML er en (relativt – nu skal jeg passe på flamerers herinde) sigende struktur som er til at forstå når man er en applikation. Og ved lagringen på harddisk eller transport over net er dokumentet zippet / komprimeret. Nettoresultat: En Word-fil i OO-format fylder mindre og er mere forståeligt beskrevet end det samme dokument gemt i Words 2003s binære format. Se, det er da elegant.

PS, Mikkel, jeg er også gerne med :-)

  • 0
  • 0
Henrik Liliendahl Sørensen

Spørgsmålet om anvendelse af XML kræver - som så mange andre spørgsmål - ikke et 'enten eller' svar.

XML er klart overlegen på mange fronter. Men der er bestemt situationer, hvor det er uhensigtsmæssigt grænsende til absurd at holde fast i en standard.

Et par eksempler:

Staten tilbyder download af OIS ejendomsdata kun som XML. Der er ikke tale om nogle elegante strukturer :-)men ganske flade filer, hvor det svære i øvrigt er at gennemskue deres indhold og sammenhæng. Der er tale om relativt store datamængder. Jeg vil tro, at det første alle gør, når man har fået de mange GB ned gennem kobberet er, at lagre dem i nogle databasetabeller. XML'en tjener formentlig intet formål - det er bare fyld i standardens navn.

I en løsning vi har leveret til brug ved match af data mod et verdensomspændende virksomhedsregister gennemføres en XML forespørgsel måske omkring en million gange om dagen. I første omgang leveredes svaret som XML. Men ved omlægge dette veldefinerede og gennemprøvede svar til et tabulator format, kunne der opnås en performance forbedring - som ganget op en million gange ikke er uvæsentlig.

  • 0
  • 0
Kristian Thy

Kåre, du skriver at man ved signering og lignende pludselig skal til at tage højde for whitespace. Det er derfor W3C har lavet Canonical XML, der godt nok kun er på Technical Recommendation-niveau, men som jeg da alligevel mener at en del værktøjer implementerer.

  • 0
  • 0
Mikkel Hippe Brun

I dette indlæg taler jeg som privatperson og ikke som repræsentant for IT- og Telestyrelsen.

Jeg undres altid når folk med længsel taler om "de gode gamle dage" hvor dataudveksling skete med kommaseparerede (CSV) filer.

Ja – jeg vil godt medgive, at CSV-filer fylder mindre, og at der kan være situationer, hvor de kan være at foretrække, hvis der er tale om tabulære datastrukturer med store mængder data. Men er der tale om mere end en enkeltstående udveksling, med lidt mere komplekse data, så er CSV-filer besværligere at manipulere og besværligere at validere.

Jeg gør mig derfor følgende antagelser i nedenstående argumentation:
* Der er tale om jævnlige udvekslinger af de samme data
* Udvekslingen skal i størst muligt omfang automatiseres

Hvis man udnytter fordelene med XML og XML Schema har man efter min opfattelse følgende fordele med XML-filer sammenlignet med CSV-filer.

XML-filer med et tilknyttet XML Schema med stærke datatyper giver automatisk validering.
Med Schematron er det muligt at opsætte endda meget komplekse validering på tværs af data (integritetsregler som vi kender dem fra relationelle databaser).
Med XSLT er det en leg at manipulere og præsentere data. En XML-fil kan omdannes til en CSV-fil med et meget simpelt XSLT stylesheet.
Versionsinformation er tydelig via namespaces. Sker der en ændring i data, så fremgår det eksplicit af importfilen fordi namespace har ændret sig. Vi får mao. ikke importeret de forkerte data i de forkerte felter. Med en intelligent versioneringsstrategi er det endda muligt importere nye versioner af XML-filer såfremt ændringen er bagudkompatibel med tidligere XML-schemaer (lidt komplekst - men muligt fx i OIOUBL – og jeg forklarer gerne teknikken offline).

Skulle jeg gøre det samme med en CSV-fil, skal jeg skrive min egen parser og manipulator i Perl, Python eller lign. Alternativt kan jeg oprette nogle tabeller i en database, som matcher data i CSV-filen og så skrive et lille script, som manipulerer data til det tabellayout jeg selv har defineret. Med denne arkitektur er jeg stærk afhængig af at de data jeg får leveret i CSV-filen ikke ændrer sig. Får jeg ekstra felter skal jeg til at debugge noget Perl / Python-kode (og det er ikke nogen let sag en time efter det er skrevet) eller også skal jeg til at tilføje felter til min database.

Jeg forstår ikke, at man vil give afkald på alle de fordele som man får foræret med XML-værktøjerne, blot for at spare lidt plads. Jeg er ikke i tvivl om at der findes domæner, hvor plads virkeligt er afgørende, og hvor antallet af transaktioner gør det nødvendigt at se kritisk på hvor meget ens XML fylder. Til militære formål og i kommunikationen med mobile enheder med små båndbredder er det helt sikkert tilfældet. I de fleste andre tilfælde er det min påstand, at den fleksibilitet man taber og den ekstra omkostning man påfører sig (ekstra kode) ikke kan opvejes af tilsvarende fordele når man vælge CSV-formatet.

Venlig hilsen
Mikkel Hippe Brun

  • 0
  • 0
Jens Madsen

Desvære kender jeg ikke til hele XML standarden, og dets mulige kombination med skemaer. For mig, er det nogle tags, der angiver en hirakisk struktur med data i - og de giver ikke mulighed for deciderede regnearksstrukturer. En udvidelse af XML, så data både kan angives hirakisk, og som regneark, vil give fordelen ved gamle CSV formater, og XML formatet samtidigt. Ellers fremstår XML som en mulighed for at opbevare konstante og tekster i felter, uden mulighed for decideret arraystruktur og data på regnearkform.

En standard pakning for XML, der automatisk udpakkes, burde også kunne integeres i XML standarden.

Det største problem, er når programmørerne også ændrer brugergrænsefladerne til at følge XML metoden: Før indtastede vi data som i et regneark i vores brugergrænseflade. Nu har vi et folde-ud træ, hvor vi skal folde hver enkelt felt ud, og editere det enkeltvis, for at opfylde XML strukturen. Det er ikke kun sket et skift med hensyn til opbevaring af data - men også i brugergrænsefladen. Det tager ca. 10 - 20 gange længere tid, fordi man nu ikke mere bare kan klikke på et felt og indtaste, samt se alle felter samtidigt på skærmen, men nu skal til at åbne hver enkelt felt. Der er ikke plads til mere, da vi altid har kunnet taste på et felt, og taste mere tekst ind i feltet, der så kunne scrolle. Prøv at tast et regneark ind på den måde. Det tager dage, i stedet for timer!

Problemet er ikke så meget i hvordan data opbevares på harddisken. Problemet ligger i, at programmørerne tænker i nye baner, og at dette styrer deres brugergrænseflade. Fra at være praktisk og brugervenligt, går det over og bliver et træsystem der er uoverskueligt, og som kun viser et eller to felter samtidigt på skærmen.

Hvis programmørerne så ikke skeler til, hvordan data opbevares internt, når de skal lave brugergrænseflader - så vil det være langt bedre. Men det som skal indtastes naturligt er i et regnearksformat, og hvor det er vigtigt at kunne se sammenhængen i kolonner, så går det totalt galt, når programmørene skifter til XML. Brugergrænseflade følger med, fordi det ændrer sig til en idiologi, og det ender i idioti.

  • 0
  • 0
Mikkel Hippe Brun

Hej Jens,

Du må endelig ikke tro, at XML lægger nogen som helst bindinger på din brugergrænseflade. Og XML bør ikke få en programmør til at tænke anderledes i forhold til brugergrænsefladen.

Som du selv skriver, er XML-strukturen, eller for den sags skyld de editeringsmuligheder du har i en XML-editor eller notepad, slet ikke velegnet som brugergrænseflade for alm. mennesker. Men det er heller ikke det der er meningen.

XML kan ikke sammenlignes med regneark, men et regneark kan som bekendt repræsenteres i XML (lad os ikke gå ned af den sti). Et regneark er en applikation som er velegnet til at præsentere tabulære data med regneregler. XML er et format der primært er velegnet til at transportere, manipulere, validere og arkivere data. XML er ikke en applikation og har ikke nogen standardiseret brugergrænseflade.

Venlig Hilsen
Mikkel Hippe Brun

  • 0
  • 0
Jens Madsen

"XML er et format der primært er velegnet til at transportere, manipulere, validere og arkivere data. XML er ikke en applikation og har ikke nogen standardiseret brugergrænseflade."

Jeg er ikke helt enig i, at XML er så ideelt som du antyder. XML er egnet til ovenstående, med et forholdsvis lille antal data. Men det er ikke et format, der er egnet til hverken at arkivere data (som f.eks. en database er). Det er for langsomt at slå op, og manipulere data, i en XML database. Jeg tror aldrig du vil finde en hurtig SQL database, der gemmer dataene i XML format.

Med et moderat lille antal data, er XML dog ideelt til at opbevare data.

XSLT gør XML interessant, fordi en "database" fra XML kan repræsenteres på en nem måde på en html side. Men XSLT har - såvidt jeg ved - ikke direkte indbygget editeringsfunktioner. Jeg syntes det kunne være yderst interessant, hvis XSLT eller et andet scriptsprog blev udviklet til at lave brugergrænseflader der også kan editere en XML fil, og includerer muligheden for "regnearksstrukturer" og foldeudgrafer i denne. Jeg har kigget lidt på XUL, men dette var ikke stabilt i den pågældende firefox (memoryleak), og dets regnearksfunktioner var ikke gode nok (et felt kunne ikke selekteres, kun en hel række), og dermed ikke godt nok til genneral brug.

XML ligger et mystisk sted - det egner sig ikke til store mængder data som regulære databaser, og der findes ikke gode nok scriptsprog, så det kan bruges til brugergrænsefladerne.

Så jeg vil nok kun bruge det til databaseudveksling, og konfigurationer.

  • 0
  • 0
Henrik Schmidt

Jens,

Der er ikke noget, der hedder "for langsomt", bare fordi der er noget, der er hurtigere. Hvis man vil arkivere nogle data i en XML fil frem for en database, så er det hurtigt nok til langt de fleste ting. Med hensyn til at slå op i data, så findes der værktøjer, i hvertfald i Java-verdenen, som kan indeksere data på en mere kraftfuld og pæn måde end SQL. Databasers store styrker som jeg ser det er deres transaktions-sikkerhed.

Med hensyn til CSV, så er det rigtigt sjovt at parse CSV, hvori der indgår både komma og linieskift i de komma-separerede data-felter. Især fordi CSV så vidt jeg ved ikke er en standard. Nej tak, jeg foretrækker XML.

  • 0
  • 0
Jens Madsen

"Der er ikke noget, der hedder "for langsomt"".

Brugerne er ikke enig.

Det er her store O funktionen det drejer sig om. Da er alt for langsomt, som ikke har ordentligt store O funktion, ved større databaser.

Og desuden betyder hastigheden utrolig meget for brugeren. Da Opera udskiftede deres funktion fra O(log n) til O(n*n), blev den ikke færdig med mine emails, trods en flere gigahertz computer. Efter 5 dages puklen gav jeg op. Det siger noget om store O funktionen. Den havde nået 20%. Men den næste procent tog meget lang tid. Det var tydeligt at se hvordan hastigheden faldt og faldt, for hver mail. Jeg stoppede da det tog 20 minutter per mail, og stadigt manglede tusinder (import fra tidligere Opera). Hent af 20.000 mails samtidigt på serveren, var også for langsomt.

Endelig er hastighed afgørende for strømforbruget. Strømforbrug, er direkte proportional med antal indstruktioner der udføres. Naturligvis skal også medregnes operativsystemets indstruktioner (interrupts), så dem der laver disse slipper ikke let, når forbruget skal ned. Har du en faktor 2 i forskel på hastighed, er det dermed også en faktor 2 i forskel på strømforbrug og batterilevetid.

På nuværende tidspunkt overskygges strømforbruget for processoren af skærmens forbrug og harddisk. Men dette gælder kun i kort tid endnu, da nye solid state harddiske også har direkte proportionalitet mellem brug og forbrug. Nye skærmtyper, bruger langt mindre strøm til baggrundsbelysningen, og det er endog muligt med passive skærme uden baggrundsbelysning, der genbruger energien der tilføres da de fleste passive skærme har kapacitiv karakter (og dermed tabsfrit).

I fremtiden vil computernes forbrug være direkte afhængig af antallet af brugte indstruktioner, og typisk vil et LiOn batteri holde et år eller to på en opladning. Det eneste som kræves, er software der ikke fråser med indstruktioner, og en anden type skærm.

Genneralt kan siges at store O funktionen altid betyder noget, hvis vi arbejder på en database der kan være vilkårlig stor (normal database).

Hvis vi har en database på fixed størrelse kan i nogle tilfælde forsvares at ikke tage højde for hastigheden, hvis størrelsen er forsvindende.

"lille O" funktionen, betyder også meget - specielt for strømforbruget i embeddede konstruktioner. Her er oftest ingen skærm, eller skærm med lav forbrug, og der er ingen harddisk. Om få år, når forbruget for skærm og harddisk kommer ned på laptops, gælder samme regler for laptops, og operativsystemet med omskrives for at opnå et lavt nok forbrug. De nuværende dræber computerens batteri på et kvarter uden at lave spor.

Fremtidssikret software, er optimeret med hastighed. Ellers kan det ikke køre på fremtidens laptops. Der er simpelthen ikke strøm nok i batteriet.

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