W3C vernieuwt XML-specificaties

Het World Wide Web Consortium, kortweg W3C, heeft deze week nieuwe releases van de vier belangrijkste XML-specificaties vrijgegeven: XML 1.0, XML 1.1, Namespaces in XML 1.0 en Namespaces in XML 1.1. Deze vernieuwde versies bevatten de correcties voor alle bij het W3C bekende fouten en extra uitleg bij delen van de specificatie die voorheen onduidelijk waren. Verder hebben W3C-medewerkers laten weten dat eind dit jaar twee nieuwe specificaties gepresenteerd zullen worden, namelijk XML Query 1.0 en XSLT 2.0. Ook wordt gewerkt aan een nieuwe revisie van XML Schema en wordt nagedacht over verbeteringen aan de XML Query-specificatie. Tot slot heeft het W3C de Efficient XML Interchange-werkgroep in het leven geroepen, die zich moet gaan bezighouden met het ontwikkelen van een specificatie die moet beschrijven hoe XML-bestanden efficiënter gebruikt kunnen worden in omgevingen waar meer eisen aan performance gesteld worden.

Reacties (36)

[Plekuz]

Vooral het laatste punt wekt mijn interesse. XML is een prachtig formaat, maar wordt herhaaldelijk gebruikt waar het niet echt voor bedoeld is. Dan bedoel ik met name in een XML een halve database pompen, terwijl het naar mijn mening altijd bedoelt is geweest als container voor een beperkte selectie van gegevens.

Dat "misbruik" is niet meer terug te draaien, maar ondertussen heeft XML wel een enorme overhead aan metadata (tags) in elk bestand, waardoor de omvang al snel helemaal uit de klauwen loopt en het niet echt geweldig performt.

Nou heb ik een tijdje terug wel wat vernomen dat er ook een initiatief was om iets van een binary XML formaat op te zetten, maar dat vind ik ook het paard achter de wagen spannen. Benieuwd wat die nieuwe werkgroep gaat bedenken.

[catfish]

waarom is het "misbruik" om een database in een xml structuur te steken?

als snelheid minder belangrijk is, is dit vrij handig namelijk

[Plekuz]

Daarom stond het ook tussen quotes. Het is natuurlijk niet echt misbruik, maar de opzet van XML is in mijn ogen geweest om het eenduidig uitwisselen van een zeer beperkte gegevensset mogelijk te maken en niet om een database van vele MB's er in te pompen.

[BikkelZ]

Liever dat je daar XML voor gebruikt dan dat je daar CSV voor gaat gebruiken. Bij XML heb je namelijk wel een correcte documentstructuur bij data over meerdere tabellen.

En je kunt eerst je ingeladen XML tree updaten in het geheugen met de juiste keys en foreign keys voordat je hem in je database jakkert, dat is wel echt ff een stuk makkelijker

[Plekuz]

Een database in CSV? Ja dan ben je helemaal lekker bezig. Om de zoveel regels een compleet andere kolomindeling, doordat je een andere tabel er in knalt. Dat is niet echt CSV te noemen. Ja er staan scheidingstekens tussen de gegevens, maar dat ik dan ook wel de enige overeenkomst. Of je moet een heel gekunstelde opzet maken, zodat wel elke regel dezelfde kolommen bevat en je de boel als dataset kunt inlezen.

[Verwijderd]

@BikkelZ:
Uit de praktijk roep ik; liever dat je daar CSV voor gebruikt dan XML. Veel soorten relationele koppelingen in databases kan je net zo min in XML als in CSV stoppen. Het garanderen van de consistentie tussen tabellen is een implementatieprobleem dat los staat van gebruikte opslagmethoden. Grote nadeel van XML is echter vooral dat het bijzonder traag in te lezen is, hetgeen zelfs al een serieus probleem wordt zelfs bij kleine databases van een paar MB's.

XML is een prima formaat voor opslag van gestructureerde (en vooral recursieve) data en ik gebruik het zelf veelvuldig, maar het is voor veel situaties ook te traag, te groot of simpelweg overbodig.

Men gebruikt voor real-time toegang van DB's voornamelijk preformatted files, voor backup/opslag/etc. vind ik zelf SQL dumps wel prettig, maar ook daar zijn tig betere formaten dan XML voor te bedenken.

[Niemand_Anders]

@mwvdlee
Wat betreft de snelheid van XML. Dat ligt er natuurlijk maar net aan met welke methode jij je XML data verwerkt.

Als je regelmatig grote XML bestanden krijgt kun het beste de XML verwerken met SAX. Wat kleinere bestanden kun je wel met DOM verwerken.

Aangezien XML bestaat uit structuur kun je beide technieken ook combineren. Je kunt met SAX je XML bestanden door racen tot je het element tegenkomt wat je zoekt. Vervolgens vraag je daarvan de data op en geef je die door aan een DOM parser.

In de meeste gevallen zijn DOM features als parents, siblings, etc niet echt nodig. SAX ipv DOM bespaart je ook aardig wat geheugen met grote XML bestanden.

[BikkelZ]

Er is niets trager als niet goed gestructureerde data.

[flossed]

De vraag is natuurlijk waar is XML goed in en waar wil je het voor gebruiken? Een tweede vraag is hoe wil je het gebruiken?

OP een project waar ik voor gewerkt heb, hebben we daadwerkelijk databases overgepompt middels XML. Met goede reden, namelijk dat er vanuit vijf verschilleden domeinen dezelfde gegevens geladen moesten worden in een nieuwe overkoepelende database. we hebben XML gebruikt omdat we daarmee de syntax van gestructureerde gegevens konden verifieren. En dat heeft er toe bijgedragen dat een groot gedeelte vervuiling van de nieuwe database voorkomen was. Dit hadden we natuurlijk ook uit kunnen programmeren maar, dan ben je meer opzoek naar programmafouten dan datafouten. En qua gegevens, geen problemen, het systeem draait nu met ongeveer 40 miljoen records, je moet het gewoon goed dimensioneren. en niet meteen 1 GB willen laden. maar stukkjes van 10 MB, lukt prima. En natuurlijk niet met DOM werken voor dit soort modellen, maar met Sax.

[ikwilhet]

Op zich een goede ontwikkeling. Ik moet nu een parser schrijven die alle versies van XML kan inlezen. Daarnaast produceren veel sites slechte xml rss feeds (denk aan threma's etc.), dan moet je vaak ook nog een error correction script maken. Dan heb je nog alle charset issues.

Nu maar hopen dat mensen snel schakelen naar de nieuwe standaard

[J.J.J. Bokma]

"nieuwe standaard"

De documenten die jij "standaard" noemt, noemen zichzelf "W3C Recommendation"

Dus als je de "standaard" wilt volgen, gebruik dan ook de naam van het document correct.

Verder, als er fouten in XML zitten, en je volgt de "standaard", dan doe je geen error correction, maar stop je met een foutmelding.

Tenslotte, een XML parser ga je niet zelf zitten schrijven, maar je gebruikt een bestaande. Het is niet eenvoudig nl.

[Verwijderd]

Voor wie het interesseert; kijk eens naar de eXist Native XML database (http://www.exist-db.org). Dit weekeinde komt 1.0rc2 uit. Het is echt erg leuk om met deze software XML based webapps te maken.
(Voor 1.0rc1 is per ongeluk Java5 nodig, voor 1.0rc2 is dat niet het geval)

[Verwijderd]

deze bieden inderdaad leuke mogelijkheden... 't is te zeggen, mits ze geschikt zijn voor je data en applicatie. Een gelijkaardig product is ook Apache Xindice...

[Verwijderd]

De ontwikkeling van Apache Xindice ligt al tijden stil (laatste update: 8 April 2004 ; zeer oude xQuery specs). Volgens SVN: laatste kleine update 3 maanden terug, de rest 12 maanden enzo....

[flowerp]

offtopic:
[quote]
(Voor 1.0rc1 is per ongeluk Java5 nodig, voor 1.0rc2 is dat niet het geval)
[/quote]

Alsof het erg is dat Java5 nodig is ofzo? Kom op zeg, over een maand komt Java 6 alweer uit. Java 5 is nu alweer zo lang uit dat het allang niet meer de nieuwe versie is die ten koste van alles vermeden moet worden.

Of is voor 1.0rc2 ook 'per ongeluk Java1.4 nodig en zal dat voor 1.0rc3 niet meer het geval zijn? Tot hoever wil je terug gaan, tot Java 1.0???

[Verwijderd]

Neuh, voor rc2 zal java4 weer voldoende zijn. Er zijn een paar kleine vervelende zaakjes over het hoofd gezien.

Enfin ; over je opmerking over Java5 ; Het project kan de stap naar Java5 nog niet maken omdat veel professionele gebruikers de database in een productie omgeving draaien, waarbij de -op een desktop gemakkelijke- switch naar een andere Java versie en-of server versie echt niet zo maar te maken is.

Maarre...... jups, een groot aantal ontwikkelaars zouden graag de stap naar Java5 willen maken. Met Java5 is Java een nog prettiger taal geworden.......

[flowerp]

offtopic:
[quote]
Enfin ; over je opmerking over Java5 ; Het project kan de stap naar Java5 nog niet maken omdat veel professionele gebruikers de database in een productie omgeving draaien, waarbij de -op een desktop gemakkelijke- switch naar een andere Java versie en-of server versie echt niet zo maar te maken is.
[/quote]


Onzin. Ik werk zelf als een software developper. De manager van onze unit vind dat "software net als wijn is, je moet het eerst een tijdje laten rijpen voordat je het kunt gebruiken", en zelfs wij zijn al een tijdje overgestapt op Java 5!

Dat is wat ik juist in mijn bovenstaande post duidelijk probeerde te maken. Java 5 is al lang uit en op dit moment gewoon helemaal de main stream Java versie. Natuurlijk stap je als bedrijf zijnde niet meteen over naar elke nieuwste versie (alhoewel, sommige zeer succesvolle bedrijven hebben dat juist weer wel als policy, maar dat terzijde).

Java 5 echter heeft al 8 updates gehad! De certificering ervoor is ook al helemaal op poten gezet. Er lopen al veel mensen rond met Java 5 certificering. Diverse grote bedrijven zitten al lang en breed op Java 5 (bv Google en Wall-mart), en veel grote paketten gebruiken ook al lang Java 5 (oa Eclipse).

Als je -nu- nog de overstap naar Java 5 predikt als een risicovolle, gewaagde stap, dan ben je gewoon FUD aan het verspreiden. De paar sectoren die mischien niet op java 5 over kunnen stappen, die kunnen waarschijnlijk NOOIT meer op een andere java versie over stappen. Als volgende maand Java 6 komt stappen ze ook niet over, en als over een anderhalf jaar Java 7 komt ook niet.

Zullen dergelijke partijen dan wel hun Java DB software gaan updaten?

Moet een project echt rekening houden met dergelijke ULTRA conservatieve bedrijven?

Ik weet niet wat jouw job is, maar als je web apps schrijft, hou je dan nog rekening met IE 1.0 gebruikers? Als je desktop software bouwt, hou je dan nog rekening met System 6 of Windows 3.1 mensen?

Een zekere mate van conservatisme is goed, maar het MOET een keer ophouden. Je kunt niet eeuwig blijven veronderstellen dat IEDEREEN antieke software gebruikt.

[martijnvanegdom]

Tuxie, toch... XML is puur een taal.. Windows onderdelen zijn geschreven in C, linux is grotendeels geschreven in C, en zijn deze compatible, dacht het niet.

Beide gebruiken XML, hun document formaten zijn gebaseerd op xml, in xml kun je gewoon een nieuwe taal defineren, dat is bij beide office suites dan ook gedaan hebben, maar ze gebruiken allebei een andere taal, die gebaseerd is op xml..

Er staat daar gewoon de waarheid

[Laurens-R]

De xml zelf bij ms is niet gepatenteerd alleen eventuele binaire delen die er in staan.... zoals gecompileerde VB, ActiveX, embedded documents van een formaat anders dan office, etc.

Wanneer krijgen mensen dit eens door. Alle document opmaak code is gewoon vrij beschikbaar.

[Billie]

En dat is dan de schuld van het W3C?

[judgem]

De link klopt niet. Het zou http://www.w3.org/2006/07/xml-pressrelease.html.en moeten zijn.

Nu is het alleen nog maar te hopen dat steeds meer partijen zich aan deze standaarden zullen houden maar de ervaring leert in de praktijk vaak anders is helaas

[StiGMaTa]

Bij mij werkt de link toch

[Verwijderd]

@judgem:

In mijn ervaring heeft het bij XML geen enkele nut om jezelf niet aan de standaard te houden. Vaak wordt een XML oplossing (ik heb het dan over professioneel gebruik, niet over hobbyen thuis) gebruikt om een mate van universele connectivity te verkrijgen.
Wanneer je dan niet jezelf netjes aan de standaard houdt haal je dat hele doel onderuit.

Bij HTML echter is het een ander verhaal, maar daar gaat dit artikel niet over dus daar gaan we het ook niet over hebben.

[hamsteg]

Ik probeer het nog steeds te bevatten maar wat biedt XML als voordeel ten opzichte van een database?

Enige argumenten die ik kan vinden:
1. portabiliteit bij uitwisseling data (tussen servers)
2. database is server-side processing, xml is client side processing.

Wat mis ik, waarom is het zo hot?

W3C - Question: When should I use XML?
Answer: When you need a buzzword in your resume.

[Verwijderd]

het hangt er allemaal wat van af wat je onder DB verstaat. Bedoel je een duidelijk gedefinieerde relationale DB, met duidelijk vastgelegde velden etc... dan blijf je natuurlijk een van de talloze DBMS'en gebruiken.

Bij XML kun je anders makkelijker "documenten" opslaan. Neem pakweg een "database" (wat je er ook onder moge verstaan) met modellen van auto's, en per auto houd je de meest onmogelijke technische details die je maar kunt verzinnen bij. Besluit je op een dag dat daar ook info over het ingebouwde GPS systeem in mag, dan hang je daar in die XML gewoon een hoop nieuwe subtags aan voor die nieuwe wagens, en je data zit er in. De bestaande oude data en modellen laat je gewoon met rust. Dat kan bv. in native XML DB's. Uw applicaties moet dan maar weten of ze die extra's tags kunnen lezen of niet. Uiteraard is dit een andere opvatting van gegevens opslaan dan een traditionele relationele DB... het hangt er ook allemaal van af dus in welke context men data wil opslaan,... er bestaan nog talloze combinaties van data-opslag en XML en het begrip DB moet je soms ruim te zien ;-) Zie ook XML Database Products

[Blue-eagle]

Simpel, waar ik werk gebruiken we voor grote sites (dataopslag) een MSSQL database. Voor kleine tot medium sites ons CMS waarin data wordt opgeslagen in XML.

Het voordeel is dat we een eigen structuur hanteren welke direct tegen een XSL stylesheet is aan te gooien. Het werkt verrekte snel in kleine data hoeveelheden en we zitten niet meer met Access databasejes te werken, hoeven geen database op te zetten, te normaliseren etc. voor iedere 'bakker op de hoek' (bij wijze van..)

Lekker simpel, overzichtelijk, weinig onderhoud en rete snel Door de eenvoudigheid van dat soort sites hebben we ook geen uitgebreide database nodig.

Verder is een XML documentje aan iedere stagair goed uit te leggen, een MSSQL database beheren, SQL queries bouwen, stored procedures.. dat is ze al snel teveel blijkt uit ervaring

[klakkie.57th]

Ik begrijp best wat je wil bereiken, maar een database is toch net wat anders dan een XML bestand.En om nu geen databases te implemeneteren omdat een stagiair er mee aan de slag moet. Dit is volgens mij de ondergang van de IT. Je moet dingen zoals database niet willen programmeren naar de eindgebruiken, het beheer hiervan is sysadmin, DBA werk niet het werk van een stagiair.

Hoe ga je dingen regelen zoals point in time restores ? je kan moeilijk iedere 5 seconden een backup nemen en die wegschrijven onder een andere naam.

[WinL]

--> in XML zijn ingewikkelde boomstructuren mogelijk. Dit lukt ook in een echte DB, maar dat is wel wat lastiger.
Maar verder heb je gelijk.

[flowerp]

Ik probeer het nog steeds te bevatten maar wat biedt XML als voordeel ten opzichte van een database?

Het zijn in weze hele andere dingen. Het slaat allebei data op, sure, maar de toepassingen zijn heel anders. Je kunt je mischien ook wel af vragen waarom we filesystems hebben om data in op te slaan, als dat ook in een DB kan, of andersom.

Soms overlappen al deze functionaliteiten elkaar wel. Het voordeel van XML is dan dat je een defacto serialisation formaat hebt. Ook een DB heeft haar gegevens natuurlijk uiteindelijk ergens op disk staan. Maar in welk formaat is dat? Losse binaire files? Raw blocks op een eigen partitie? Welk formaat het ook is, in veel gevallen is het niet makkelijk een file'tje die je even overstuurt.

Daarbij komt, je kunt een XML file makkelijk onder versie controlle zetten en het kan zowel met tools die het speciale formaat herkennen ge-edit worden als met de hand.

Als voorbeeld, neem bijvoorbeeld het web.xml bestand in een (java) web applicatie. Dit is een bestand dat configuratie data bevat. Je zou dit ook vanuit een DB kunnen laden, maar dat is redelijk onzinnig. web.xml is pure statische data dat in z'n geheel regel voor regel verwerkt moet worden.

Een DB zou handig zijn als het om dynamische data gaat (data die tijdens de runtime continue veranderd wordt) en waar er sprake is van specificieke items die op request benaderd moet worden. Bij een configuratie bestand is dat allemaal niet van toepassing.

Zelfs als je wel specifieke data 'items' wilt, kun een DB vrij zinloos zijn. Neem bijvoorbeeld i18n keys. Je wilt niet voor elke key een query naar je DB doen. Dat is veels te langzaam. Zogenaamde i18n resource bundles worden dan ook direct in het geheugen geladen en in een hashmap geplaatst. De keys kunnen dan in een XML bestand geplaatst worden, dat dan puur en alleen als simpel serialisatie formaat dient.

Weer een andere toepassing is als het om kleine chunks van data gaat met een sterke hierarchy. Neem bijvoorbeeld JSF pagina layouts. Deze beschrijven in XML de layout van een pagina, waarbij components genest zijn en vele attributen hebben. Dit soort data kun je echt niet met goed fatsoen in een relationeel model stoppen. Je editors zouden dan de gehele pagina beschrijving als 1 object uit de DB moeten trekken. Dat kun je doen, maar je hebt dan nog steeds het XML formaat nodig voor de interne structuur nodig.

[spep]

w3c is een ongeorganiseerd zooitje hobbisten bij elkaar

iets wat vorige maand nog goed was ( geen errors in html 4.01 ) is opeens niet meer goed zonder ook maar 1 letter tehebben veranderd

[Stijn]

Jij baseert een oordeel over het W3C op het falen van één van jouw pagina's in hun HTML validator?

[q2no]

Het zou alleen handig zijn als ze alle info in een een off-line document (pdf oid) hadden weggeschreven. Alles netjes per hoofdstuk etc. Net even copy / plak gedaan naar Word, maar dan heb je 50 pagina's zonder enige structurele opmaak....

[Verwijderd]

printen naar pdf of de html opslaan..