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.
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.
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.
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.
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.
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 >
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.
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.
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…
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.
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.