XML is net zo overschat als de magnetron

23-05-2009 18:34 | Door Freddie van Rijswijk | Lees meer artikelen over: XML , Processoren, Processoren | Lees meer over het bedrijf: Google | Er zijn 18 reacties op dit artikel | Permalink
Computable Expert
Freddie van Rijswijk
Freddie van Rijswijk MSc

Senior Executive

Expert van Computable voor de topics: ECM en Architectuur

Meer

Ik ben op zoek naar een onderbouwde verklaring waarom XML en aanverwant XSL voor ieder ict-probleem als oplossing naar voren wordt geschoven. Wanneer kan ik de klant een compliment geven voor zijn keus voor XML?

De vergelijking met de magnetron in de jaren '80 is frappant. Toen werd de magnetron voor iedere kookklus naar voren geschoven inclusief de bijbehorende accessoires voor het bruinen van vlees, bakken van een ei, etc.

Momenteel zien we niet alleen XML en XSL in de web- en soa-wereld, maar leveren meer en meer bedrijven hun gegevens aan in XML-formaat voor massaverwerking. Niet omdat dit effectief en efficiënt is, maar omdat de bedrijfsarchitect XML heeft voorgeschreven als de bedrijfsstandaard. Ja, die architect die zelf nog nooit één regel code heeft geschreven of voor een projectdeadline wekenlang nachten en weekeinden heeft door moeten halen en ook geen rekening heeft gehouden met het feit dat de processorcapaciteit in nachtelijke uren voor alle batchprocessen al volledig gebruikt wordt.

Kortom, wanneer is XML wél een goede keus en wanneer niet?

Het feit dat iedereen het doet is niet genoeg voor mij. Dat tagging een goede keus kan zijn voor het web (html) kan ik in meegaan. Echter, volgens mij is XML het slechts denkbare formaat voor gegevensuitwisseling en interfaces. De hoeveelheid bytes die nodig zijn voor de tags is een veelvoud van de daadwerkelijke informatie. Het feit dat het gelezen kan worden door niet-ict-mensen is volgens mij een argument wat geen houd snijdt. Welke niet -ict'er leest een XML? XML is niet een standaard. Dat je een tag kunt beschrijven in een XSD geeft volgens mij niet meer voordelen dan een simpele binaire pointer/lengte-structuur terwijl deze laatste veel efficiënter is. Google bewijst dit met zijn Protocol Buffers en daarvoor was het Corba’s IOP. De benodigde processorcapaciteit voor het valideren en parsen van de XML maakt het tot CPU-intensieve en zeer langzame oplossing. Kortom, XML is niet gemakkelijk, goedkoop, simpel en robuust. XML is een hype en niet in overeenstemming met de realiteit, maar dit is niet de schuld van XML.

Ps. Ik hoef geen uitleg over XML, XSL, XSD ik ben op zoek naar onderbouwde verklaringen en geen lege claims.

Reacties op dit artikel
Geen ratingErwin Rijss, 25-05-2009 12:50
Mijn eerste gedachte is dat XML praktisch is omdat het een dataformat biedt dat onhankelijk is van het medium waar het in opgeslagen was of waar het in opgeslagen moet worden. Door gebruik te maken van een XSL transformatie kun je de data eenvoudig omzetten naar het specifieke format dat door jouw importer wordt ondersteund.
 
Echter, wanneer je je dat een ander formaat aangeleverd krijgt zul je ook een transformatie moeten programmeren. Alleen dan met een andere taal dan XSL. Dat XSL een W3c standaard is en een stuk programmcode niet doet daar eigenlijk niets aan af.
 
De opkomst van Javascript Object Notation (JSON) bewijst eigenlijk het gelijk van jouw stelling; er wordt al gezocht naar een efficientere manier om data uit te wisselen.
 
Blijft misschien de elegantie van XML als enig steekhoudend argument over: XML is de haute couture van de data-uitwisseling en haute couture, tja, dat kost nu eenmaal geld.
Geen ratingNiek, 25-05-2009 12:59
Ik ben geen xml-specialist maar maar het volledig met de stelling eens dat xml door de enorme overhead geen geschikt protocol is voor het verwerken van grote hoeveelheden data. Bijvoorbeeld bij webapplicaties is het gebruik van het Json protocol ( http://www.json.org ) voor de communicatie tussen server en client veel geschikter.
Geen ratingJan-Willem de Koning, 26-05-2009 0:24
XML is ooit bedacht om publicatieprocessen voorspelbaar en effici?nt te maken. Het grote voordeel van XML daarbij is dat het in zichzelf verklarend en gedocumenteerd is. Dat is een groot voordeel tov andere, mogelijk effici?ntere, standaards. Voorts biedt het als opslag formaat de mogelijkheid om content te beheren en vervolgens op verschillende platforms (boek, website, PDA etc) te publiceren, al dan niet in verschillende samenstellingen. Voor publicatieprocessen is dat een enorme stap voorwaarts gebleken.
Geen ratingEd Steenhoek, 26-05-2009 8:51
Ik weet niet of de magnetron overschat is/was. XML is dat zeker. De mythe dat het in zichzelf verklarend en gedocumenteerd is blijft maar voort duren terwijl het pertinent onjuist is. Je k?nt XML zo 'schrijven' dat het leesbaar en begrijpbaar is maar dat is geen afgedwongen standaard. Het fragment 1 is net zo valide XML als 1 maar w?l 'goedkoper' en voor de ontvanger net zo eenvoudig te verwerken. In beide gevallen moet de ontvanger namelijk de context bepalen uit een separaat gedocumenteerd afspraak. Of dit nu een XSD schema is of anderszins.
 
Voor een goed oordeel moeten we terug naar de roots. XML is een vereenvoudigde versie van SGML. En waarom is SGML ontwikkeld door IBM in de jaren 60? Om het mogelijk te maken dat door computers leesbare documenten gedeeld kunnen worden tussen meerdere systemen ?n dat gedurende vele decennia. Er mocht dus geen afhankelijkheid zijn van IT middelen. En dat is toen met SGML geslaagd. (HTML is ook gebaseerd op SGML en voldoet redelijk voor haar doel maar is niet meer valide t.o.v. SGML.) XML is gemaakt om als basis te dienen voor document-standaarden zoals XBRL. Pas dan heeft XML toegevoegde waarde: binnen een industrie geaccepteerd als standaard. Hoewel de keuze arbitrair is (waarom geen JSON...), is n? het stellen van de standaard het voor de betrokkenen veel effici?nter om data uit te wisselen.
 
En de magnetron? Dat is d? oplossing om snel te ontdooien of te verhitten.
Geen ratingEd Steenhoek, 26-05-2009 8:56
Jammer dat een reactie met xml tags geinterpreteerd wordt terwijl accenten slecht doorkomen... nog een poging:
 
De eerste 1 was bedoeld als:
< x > 1 < / x >
 
De tweede 1 was bedoeld als:
< huisnummer > 1 < / huisnummer >
 
Geen ratingGert-Jan van Lochem, 26-05-2009 9:30
SGML is bedacht in de hoek van de Technische Documentatie om natuurlijke taal automatisch verwerkbaar te maken. Ook XML heeft de kracht om dat te doen.
 
Daarmee is het wellicht te zwaar om de standaard voor een een-op-een uitwisseling van eenvoudige gegevens tussen twee systemen te zijn.
 
Zodra er echter weer veel partijen bij betrokken zijn (ketenautomatisering) of er verder gekeken moet worden dan die ene interactie is een echte open standaard vaak de beste optie (hoe bewaak je de consistentie over verschillend bedrijven tussen JSON definities?).
 
XML is overigens formeel zeker een open standaard, maar de meerwaarde zit 'm in een op een domein toegespitste XSD, zoals Ed ook al schrijft.
 
Je grieven gaan zo te lezen vooral over de Overhead en het dure Parseren.
Overhead zie ik zelf in de huidige wereld van breedband en goedkope opslag niet echt als een probleem - wellicht wel in extreme high volume processing.
Het dure Parseren is een steekhoudend argument. Ik zie dat veel partijen worstelen met het real-time Parseren. Dit is deels een erfenis van de kracht van XML, maar ik ben het met je eens dat de ICT wereld daar een efficientere oplossing kan gebruiken.
Geen ratingPeter, 26-05-2009 10:42
XML is van oorsprong helemaal niet bedoeld om voor zoveel toepassingen gebruikt te worden maar blijkt in de praktijk zich te bewijzen. En dus ook steeds breder gebruikt blijft worden ok al wordt er vaak zat fout gebruikt of zelfs misbruik van gemaakt.
Wat XML voor zich heeft is dat je anders 1001 'standaarden' krijgt van gegevens uitwisseling en de daarbijbehorende problematiek. Bijv datum/tijd/tijdzone notatie.
Geen ratingAllard Buijze, 27-05-2009 8:24
XML is vaak de makkelijke weg als je op zoek bent naar een formaat dat door meerdere systemen geinterpreteerd kan worden. Alle programmeertalen bieden wel ondersteuning bij het parsen/genereren van XML berichten. De luie ontwikkelaars zullen dus meteen terugvallen op XML. Bij een "custom" formaat moet je dat allemaal zelf doen.
 
Je zou kunnen zeggen dat XML nog steeds heel handig is voor de luie mens. En iets dergelijks kun je van de magnetron natuurlijk ook zeggen...
Geen ratingJochen Szostek, 27-05-2009 9:55
Interessante topic! Denk dat ik misschien wel beetje als underdog ga overkomen hier, maar soit:
 
Ik vind XML best wel ideaal voor toepassingen als de declaratieve layout van GUI's op te bouwen. Zo zie ik duidelijk de structuren die ik visueel in elkaar steek en omgekeerd. Kan me der eerlijk waar zelfs niets beters voor inbeelden. (Flex en zijn mxml bv.)
 
Ook voor de configuratie van beans (in bv. Spring) indien deze aanpasbaar moet zijn tijdens runtime vind ik ideaal via XML. Kan me hier ook niet direct een beter alternatief voorstellen. (annotations + properties files mss enigszinds)
 
Ook XHTML vind ik een grote vooruitgang tov HTML uiteraard. Kan me hier ook bijna enkel veel positieve beken
 
Waar ik wel volledig mee eens ben is dat de verzending (door tag overhead) en de verwerking van XML (tov andere binaire oplossingen bv. Adobe's AMF formaat) in webservice systemen, geen goede oplossing is.
Geen ratingMarc van Grootel, 27-05-2009 12:12
Het belangrijkste argument dat ik uit dit artikel haal is performance gerelateerd (verhouding data/tags, verwerking van XML data). Dat doet me enigszins denken aan de discussie tussen echte programmeertalen en scriptingtalen (die nu steeds vaker dynamische talen genoemd worden). Een scriptingtaal zou te langzaam zijn voor het echte werk. Daarnaast het dedain van de 'echte programmeurs' dat scripting geen 'echt' programmeren is. Natuurlijk is XML niet de oplossing voor alles en zul je een afweging moeten maken zoals ook Google gedaan heeft met protocol buffers. Maar in tijden van cloud-computing, los gekoppelde services, web data, syndicatie van feeds en wat al niet meer is de rol van XML erg groot en belangrijk. In deze context lijkt me het terugvallen op 'simpele binaire pointer/lengte-structuren' niet zo'n gezonde keus (maar het maakt me bijv. niet uit wanneer delen van m'n keten hier juist wel gebruik van maken om bepaalde performance voordelen te behalen).
 
XML komt voort uit SGML en dat was vooral een documentatiestandaard maar is mi. ook in de uitwisseling van data tussen verschillende systemen van groot belang. JSON is voor dit soort informatie bijvoorbeeld ook ongeschikt (door de mixed content in documenten iets dat in data uitwisselingsformaten minder gangbaar is) en voor je 'simpele binaire pointer/lengte-structuur' oplossing geldt dat nog sterker. Microsoft is voor het formaat van hun Office producten overgegaan op XML en het is nu veel eenvoudiger om echte Office documenten een server te genereren zonder dat er ook maar ��n door Microsoft geschreven regel code aan te pas komt. Ikzelf heb ook verschillende keren een foute inschatting gemaakt en XML toegepast voor een probleem waarvoor het achteraf niet zo geschikt was. Fouten maken is menselijk als je maar telkens nieuwe fouten maakt ;-)
 
Voor XSLT en XQuery geldt dat het tools zijn die goed passen bij het verwerken van XML. Niet altijd de meeste geschikte tool maar er komen steeds meer native XML databases zoals van Mark Logic waarmee een totale XML oplossing mogelijk wordt die ook nog goed genoeg performt. Parsers en validatie te langzaam: ik denk dat dit nog wel op te lossen door door goede ontwerpkeuzes te maken en door de voortschrijdende technologie (de historie staat me daar in bij, als het probleem belangrijk genoeg is komen er wel oplossingen voor er is inmiddels zelfs XML hardware te verkrijgen). Dat XML een groter beslag legt op processorcapaciteit staat buiten kijf, maar ineffici�nte algoritmes of een spaghetti van (legacy) systemen zonder XML doen hetzelfde. Met XML heb je toch een soort meta-lingua franca te pakken waarmee zowel slechte als goede talen of formaten in elkaar te knutselen zijn en die je in staat stelt om solide ketens van informatiebewerking samen te stellen. Natuurlijk hoeven niet alle delen via XML te lopen. Google is inderdaad een goed voorbeeld omdat protocol buffers effici�nter zijn dan XML of JSON over de draad sturen. Maar ze bieden in hun API's ook JSON en XML alternatieven die gebruikt kunnen worden wanneer processorcapaciteit of performance niet de hoogste prioriteit hebben. En dan zijn daar natuurlijk ook de verschillende, streaming of non-streaming API's. Bij de implementatie van systemen moeten veel keuzes gemaakt worden (bijv. ook non-validating of validating parser). Soms is processorcapaciteit leidend maar lang niet altijd, soms is eenvoud, snelheid van implementatie en inzichtelijkheid van groter belang (zoals dat ook een rol speelt bij de inzet van scripting/dynamische talen). De voordelen hiervan kunnen zich vertalen in goedkopere systemen, sneller kunnen inspelen op veranderende eisen e.d.

Ik werk in de technische informatie- en documentatiesystemen en daarvoor in de lokalisatie. Ik moet zeggen dat hier (waar het gaat om documenten en dus niet alleen relatief eenvoudige data structuren) XML een zegen was en is. Alleen al vanwege het eenvoudige feit dat het ervoor gezorgd heeft dat dit soort complexe structuren als Unicode verwerkt worden en ik niet allerlei ingewikkelde fratsen hoef uit te halen om een Engelse XML naar andere talen zoals bijv. Chinees of Arabisch om te zetten. Er zijn inmiddels zoveel goede libraries en parsers om met Unicode XML om te gaan dat ik me hier weinig zorgen meer om hoef te maken. Unicode staat weliswaar los van XML maar is wel een voorbeeld waar de bytelengte van data behoorlijk kan vari�ren en een pointer/lengte-structuur oplossing lastig wordt.
 
Ook vind ik het juist wel een voordeel dat het eventueel door mensen gelezen kan worden of in ieder geval in bijna iedere tekst editor geopend kan worden. ICT-ers zijn ook mensen, en mensen maken fouten, een formaat dat eenvoudig te lezen is (hangt wel af van het soort XML) en in een editor bijv. m.b.v. XPath (welke op alle XML werkt) te doorzoeken is maakt het makkelijker fouten op te sporen en te leren. Ik zie dit met op maat gemaakte en eventuele proprietary data formaten niet zo makkelijk werken.
 
Volgens mij kun je je klanten complimenteren als hun toepassing of data blijk geeft van een goede afweging van wanneer of waar wel of niet XML ingezet wordt, dus goed binnen de context van het probleem (en die context is vaak veel breder dan een enkele gebruiker of gebruikersgroep). Ook de keuze tussen een bepaalde standaard of het zelf maken van de datastructuren valt hieronder. De magnetron is uitermate geschikt om snel zaken op te warmen maar een goede kok weet de verschillende bereidingswijzen met elkaar te combineren tot een goede maaltijd. Een goede kok is volgens mij ook niet bezig met of de ��n of andere bereidingswijze overschat wordt. Sommige koks grijpen sneller naar de magnetron. Andere mensen willen zo weinig mogelijk tijd aan het bereiden van hun maal besteden en nemen het op de koop toe dat het niet zo lekker krokant is.
Geen ratingJochen Szostek, 03-06-2009 9:04
Mooie benchmark app om XML / binaire transmissie te vergelijken: http://www.jamesward.com/census/
Geen ratingBen Tels, 11-06-2009 14:13
Freddie,
 
De grote voordelen van XML zitten voor mij in het feit dat XML niet aan een platform gebonden is en dus een simpel medium is om data over te zetten tussen heterogene systemen. Sterker nog, XML stelt zo weinig platformeisen dat je een service met XML communicatie kunt bouwen zonder precies je afnemers te kennen.
 
Je noemde JSON als een alternatief; dat kan ongetwijfeld wel. Maar als een van beide kanten van een communicatielijn niet een JavaScript engine is, zou ik er minimaal tweemaal over nadenken om JSON te gebruiken.
Geen ratingVincent van Gentevoort, 15-06-2009 10:36
Belangrijk succes element van een standaard is dat deze breed gedragen wordt. Fundamenteel als het om uitwisseling gaat. Dat is XML nog als geen ander gelukt, dat kan je niet onderschatten. HTML is niet optimaal en schiet te kort met wat we tegenwoordig doen.
 
Dat iedereen het doet is juist essentieel voor het succes. Dat er technisch betere alternatieven zijn is mooi maar het zal breed gedragen moeten worden om succesvol te worden.
Veel alternatieven zijn binnen minder dan handbereik. XML heeft de basis gelegd voor een open en makkelijke manier van gegevens uitwisseling.
 
Grappig dat je Corba noemt, voorbeeld van een complex mechanisme en daardoor niet zo'n succes.
Geen ratingBob Ambrosius, 15-07-2009 17:02
Freddie gooit de knuppel in het hoenderhok. En de kippen gaan tekeer...
Ik wil het vraagstuk wat generieker formuleren. Ik zie dan even af van losgeslagen bedrijfsarchitecten en de magnetron als panacee. De vragen zijn dan: welk probleem lost XML op, en welke nadelen heeft de oplossing. We beginnen met de nadelen. Freddie benadrukt het grote nadeel van XML: de payload ? de echte inhoud ? is qua omvang een fractie van de totale berichtomvang. Daarmee is meteen duidelijk dat XML niet effici?nt is. Dat is een nadeel wat men moet afwegen tegen de voordelen. En als iemand helemaal niet met dat nadeel kan leven dan is de oplossing in die situatie gewoon niet geschikt. Punt. Iemand die een magnetron aanschaft om een ei te bakken moet niet klagen dat het ei niet te vreten is en dat dus een magnetron een waardeloos product is. En als de marketingafdeling van de magnetronproducent het apparaat voor dit gebruik aanbeveelt moet die producent aangeklaagd worden. Elke oplossing kan men in de verkeerde situatie toepassen, maar dat maakt de oplossing alleen maar slecht in die situatie, niet in zijn algemeenheid. Ik volg daarmee de argumentatie van Marc van Grootel.
 
Zoals elke oplossing heeft XML ook voordelen. Het feit dat XML niet reeds na een paar jaar een zachte dood is gestorven maar zelfs een grote vlucht heeft genomen doet vermoeden dat men deze oplossing niet kan afdoen als een hype die iedereen maar toepast omdat alle anderen dat ook doen. En er is een voordeel; dat voordeel moet gezien worden in het licht van het probleem: de kwaliteit van berichtgegevens is slechts zeer moeizaam vooraf controleerbaar. Die kwaliteit is belangrijk want we weten dat hoe verder in de procesketen een fout wordt gevonden des te duurder het herstel is.
 
Het volgende is een re?el geval. Ik krijg gegevens aangeleverd in het CSV formaat. Voordat ik die gegevens ga verwerken wil ik er eerst zeker van zijn dat ze aan de kwaliteitseisen voldoen.
1.Staan de kolommen in de volgorde die is afgesproken.
2.Zijn alle kolommen aanwezig.
3.Hebben de kolommen de afgesproken naam.
4.Behoren de gegevens onder een kolomkop allemaal tot de categorie die de kolomkop duidt (en wat duidt de kolomkop inpnr ook al weer?).
5.Behoren de gegevens onder een kolomkop tot het afgesproken datatype (datum, getal, bedrag, string, enumeratiewaarde!)
6.Daar waar sprake is van 1:n situaties, is het aantal n dan volgens afspraak.
7.Zijn verplichte gegevens allemaal aanwezig.
8.Is het aantal rijen niet groter dan afgesproken.
9.Is de gekozen ?Character Encoding? conform afspraak.
Voor al deze controles moet ik code schrijven. Inderdaad, ik ben geen bedrijfsarchitect en heb me aan projectdeadlines te houden. Ik verwacht dat de leverancier van het bericht de kwaliteit ook controleert; maar omdat die op een ander platform werkt heeft die niets aan mijn code, dus die schrijft (hoop ik) ook code, gebaseerd op onze afspraak over de kwaliteitseisen. En verder ontvang ik natuurlijk niet berichten van slechts een type, maar van vele typen. Dus nog meer code. En verder ontvang ik van meer partijen berichten. Elke maakt (hoop ik) op zijn eigen platform code om het bericht vooraf te controleren. Ik hoop maar dat noch ik, noch mijn leveranciers ooit over hoeven te gaan naar een ander platform, want dan kunnen we weer opnieuw beginnen. Daar is natuurlijk geen geld voor, dus accepteren we de gegevens maar zonder kwaliteitscontrole vooraf; we zien wel wat er verderop in de keten gebeurt. Tenslotte is het onzichtbaar dat de gegevens kwaliteit ontberen...
 
Dit nu is het probleem wat XML oplost: het maakt kwaliteitcontrole mogelijk. Maar let op, het is niet de *vorm* van XML ? tags toevoegen volgens de voorschriften ? die het 'm doet. Tags zijn een noodzakelijke voorwaarde om het bericht, de instance in goed Nederlands, te vergelijken met een berichtspecificatie waarin dezelfde tags genoemd worden en waarin in formele taal is weergegeven wat de kwaliteitseisen zijn. De berichtspecificatie krijgt gestalte in een XML Schema. De leverancier en ik downloaden beide een 'XML engine' die past op ons platform. Daarmee confronteren we elke instance met het schema. De XML engine vertelt ons waarin niet wordt voldaan aan de kwaliteitseisen.
 
Dat is heel wat code die niet meer nodig is. Dat levert besparingen op. Een deel daarvan gaat weer op aan het samenstellen van het best wel ingewikkelde XML Schema waarin we onze kwaliteitseisen vastleggen. Maar als we het goed doen kunnen we een XML Schema maken dat de kwaliteitseisen van diverse berichttypen bevat, en dan besparen we weer wat aan onderhoud.
 
Zonder extra inspanning levert de XML werkwijze ons nog meer voordelen op: 1) We hebben een instrument om de kwaliteitseisen waterdicht te formuleren, want laten we wel wezen: onze vorige afspraak stond bol van de dubbelzinnigheden. 2) we kunnen de instance 'renderen' met XSL stylesheets. Daardoor worden berichten met een ingewikkelde structuur voor mensenogen toegankelijk gemaakt. Kleuren en opmaak helpen bij het beoordelen van het bericht. 3) We lopen geen risico meer bij een wisseling van platform.
 
Pas de XML oplossing vooral *niet* toe in de situatie waarbij vijf miljoen berichten in tien minuten verwerkt moeten worden. Dan krijg je in ieder geval niet het nadeel; maar het voordeel ook niet natuurlijk.
Geen ratingFreddie, 15-08-2009 23:32
Een opinie met 14 reacties, voor en tegen maar allen voorzien met goede argumenten. Dank voor alle reacties, ik hoop dat wij allen en de vele lezers er iets aan hebben bij de afweging wel of niet XML te gebruiken.
Geen ratingDick Deneer, 21-08-2009 17:57
Freddie van Rijswijk vindt XML het slechts denkbare formaat voor gegevens uitwisseling en interfaces en vraagt zich af waarom iedereen er toch voor kiest.
Alle argumenten die in het artikel worden genoemd hebben eigenlijk betrekking op de "fysieke" ineffici?ntie van het XML formaat en dit valt inderdaad niet te ontkrachten. Ik ben het met de schrijver eens dat bij batchverwerking XML niet altijd een voor de hand liggende keuze is. Als er geen communicatie is met andere partijen kan het zelfs soms op sommige platformen een redelijk onzinnige keuze zijn.
De vele open en sluit tags maken het bestand vaak enorm groot. Door het bestand niet te formatteren (bij formatteren komt ieder element op een nieuwe regel en wordt ingesprongen voor nivo's) kan wel iets ruimte worden gewonnen, soms 50%. Het parsen van XML is natuurlijk lang niet zo effici?nt als de verwerking van fixed-length records of pointer structuren. Als je vroeger op een IBM mainframe met Cobol een XML bestand ging parsen dan was hier nauwelijks ondersteuning voor. Later kreeg COBOL ingebouwde XML ondersteuning. In de tijd dat ik het gebruikte weliswaar nog zonder validatie en namespace support en met de eis dat de complete XML in geheugen moest worden geladen om te kunnen parsen. Tegenwoordig levert IBM z/OS XML system services en daarmee zijn eigenlijk alle beperkingen weggenomen. Het is een zeer effici?nte parser waarmee het ook mogelijk is om het cpu intensieve parsen uit te laten voeren op een soort hulp processor. Dit is goedkoper en houdt de hoofdcpu beschikaar voor andere processen.
 
De keuze voor XML is echter gebaseerd op andere zaken.
1. Bij het bouwen van een interface of service is het makkelijk om gegevens uitwisseling met de ander partij vast te leggen in een xml schema. Dit is eenduidiger en met meer detail dan een bestand- en record beschrijving in de traditionele vorm, waarbij iedereen zijn eigen manier van vastlegging koos. Het XML schema kan bovendien direct in de bouwfase ingezet worden zonder een vertaalslag te moeten maken. Met XML is de communicatie tussen programmeur, ontwerper en gebruiker een stuk makkelijker geworden; dat vergroot de slagingskans van een project.
Er zijn veel XML tools op de markt. Hierdoor kunnen van de XSD voorbeeld-bestanden of berichten worden gemaakt en de structuur kan ook grafisch worden getoond. Er is geen discussie of de geleverde in- of output wel goed is, omdat deze onafhankelijk van de overige programmatuur gevalideerd kan worden tegen een schema.
2. XML kan op een natuurlijke manier hi?rarchische structuren weergeven. Met andere formaten blijft dit toch altijd een beetje behelpen. Als je fixed-length records hebt draait het al snel uit op het maken van verschillende record-types met voorloop- en afsluitrecords. Structuren die met pointers werken zijn veel minder uitwisselbaar.
3. Ook voor herhalende groepen en "NULL" waarden geldt dat traditionele bestandformaten hier minder inzichtelijk mee omgaan.
4. XML bestanden kunnen gemakkelijker uitgebreid worden met extra informatie zonder dat de verwerkende programmatuur deze direct hoeft te verwerken. Hierdoor kunnen aanpassingen makkelijker worden doorgevoerd. Dit is niet mogelijk in een fixed-length bestand.
5. Tooling en standaarden bepalen vaak de keuze voor XML. Voor een programmeertaal als JAVA geldt dat het werken met XML enorm goed wordt ondersteund. Met behulp van een XML digester kunnen XML elementen en attributen direct naar java objecten worden gemapped. Als je nu een webservice maakt, kies je waarschijnlijk voor SOAP en dus voor XML.
6. De leesbaarheid van XML maakt de uitwisseling makkelijk. Maar ook in de testfase is het makkelijk. Zonder het tellen van posities of een hexadecimale editor is het mogelijk om bijvoorbeeld testbestandjes aan te maken. In het algemeen is XML onderhoudsvriendelijk.
 

Bovenstaande maakt duidelijk dat XML niet misschien het meest effici?nte formaat is. Maar XML is zeker simpel, robuust, gemakkelijk in de communicatie en de verwerking.
 
Geen ratingThe Van, 28-08-2009 14:11
Ik weet waar Freddie geweest is, en zijn inspiratie vandaan heeft. Ik zit met zo'n geweldige implementatie, waarbij XML in de database opgeslagen wordt. Vervolgens wordt deze "bewerkt".
Zowel opslagtechnisch (20GB/60k entries) als performance-technisch (10k records/uur) een disaster.
Geen ratingTj.Beets, 12-10-2009 20:42
Als XML staat voor structuur, betekenis, generiek en ten slotte ook nog nieuw? en internet gerelateerd? dan wordt aan veel ingredienten voor een hype voldaan.
Het gesignaleerde probleem, heeft niets met XML te maken maar alles met de manier waarop we met ons vak bezig zijn. Andere voorbeelden zijn 'relationeel(van het RDBMS)' en recent SOA-ESB.
In ons vak - ik moet het helaas bekennen - zijn we nog maar nauwelijks in staat om de stap te maken van:
a. wat zou je er allemaal mee kunnen, naar
b. waar moet je het eigenlijk niet voor gebruiken, en
c. waar moet je het zeker niet voor gebruiken.
Het lijkt beschamend, maar waar wordt in welke cursus aan de startende XML-goeroe uitgelegd dat 'een magnetron niet het goede hulpmiddel is om een nat huisdier te drogen'.
Elk nadeel 'heb ze voordeel' nadenken hierover geeft veel inzicht, vooral ook in je eigen vakmanschap.
Uitdaging: maak uit dit artikel en de talrijke reacties een a, b, c lijstje, inclusief korte motivatie
Genoeg stof voor een serie instructieve artikelen en een e-book.
6 vacatures
MS Dynamics NAV Specialist

Ammeraal Beltech B.V. , Heerhugowaard

Co\u00f6rdinator datawarehouse

Inspectie van het Onderwijs, Directie Kennis , Utrecht

Database Administrator

Waterland Ziekenhuis , Purmerend

Data Migration IT Specialist

Uitzendburo de Werkstudent , Amsterdam

Senior Database Administrator

VWE voertuiginformatie en -documentatie , Heerhugowaard

Top 10 Reagerende members
  Aantal reacties
met 3+ sterren
Gemiddelde
waardering
Klik voor meer info1 1561 6.2
Klik voor meer info2 1297 6.0
Klik voor meer info3 1266 6.2
Klik voor meer info4 1068 6.2
Klik voor meer info5 976 6.1
Klik voor meer info6 901 6.1
Klik voor meer info7 755 6.2
Klik voor meer info8 520 6.1
Klik voor meer info9 397 6.0
Klik voor meer info10 391 6.2