W3C overweegt binaire XML-standaard voor meer snelheid

Het W3C overweegt om een binaire versie van de universele datataal XML te gaan ontwerpen. De huidige standaard is volledig gebaseerd op platte tekst, die net als HTML makkelijk door mensen te lezen, maken en aanvullen is. Volgens het standaardenorgaan zou een binaire versie echter compacter en sneller door computers te verwerken zijn, waardoor XML beter geschikt zou worden voor apparaten waarin zaken als rekenkracht en bandbreedte beperkt zijn. Niet iedereen is het echter met deze argumenten eens; tegenstanders zijn vooral bang dat het de compatibiliteit met bestaande software ernstig zou breken. Bovendien zou het probleem van traagheid automatisch opgelost kunnen worden door nieuwe ontwikkelingen op het gebied van technologie. Als men nu zou besluiten om een 'snellere' standaard te gaan ontwikkelen zou het namelijk makkelijk drie jaar kunnen duren voor versie 1.0 af is. Tegen die tijd zal ook normale XML veel sneller zijn, puur vanwege de betere hardware en snellere (draadloze) netwerken die tegen die tijd beschikbaar zijn.

Toch bestaat er wel degelijk een behoefte aan een binaire vorm van XML, getuige het feit dat ruim tien bedrijven inmiddels een eigen formaat hebben ontwikkeld of aan het ontwikkelen zijn. Niet iedereen is er echter van overtuigd dat alle specifieke behoeftes van deze bedrijven in één standaard te combineren zijn. De komende tijd zal het W3C de wensen van de industrie gaan inventariseren, zodat aan het eind van de zomer een besluit kan worden genomen over het al dan niet ontwikkelen van een binaire XML-standaard.

Reacties (50)

[Verwijderd]

Waarom moet het zo ingewikkeld? Het snelheidsverschil tussen gecompileerde (binaire) en normale xml is toch nihil? Of zie ik dat verkeerd..
Edit: waarschijnlijk wil de industrie dit omdat binaire informatie ook makkelijker beveiligd kan worden, en wordt het ook mogelijk om xml bestanden van een password te voorzien

[Onno]

Het snelheidsverschil tussen gecompileerde (binaire) en normale xml is toch nihil? Of zie ik dat verkeerd..

Ja. Een (goed) binair formaat inlezen kan veel sneller dan een tekst-formaat als XML parsen.

[Jeroen V]

Groot nadeel is wel dat veel platformen andere binaire representaties hebben van bepaalde waardetypen waardoor de uitwisselbaarheid van dergelijke binaire bestanden een probleem op zou kunnen leveren.

Denk aan signed en unsigned, BCD, julian date.... En zo kan je nog wel even doorgaan. Ik ben benieuwd wat voor oplossingen daarvoor gevonden gaan worden.

[Jeroen V]

@Olaf: Stuur maar een getal als binaire data. Als je hexidecimaal een 10 verstuurt, dan is dat als unsigned byte binair 1010 gezien, stuur hem als packed BCD en het is 10000. En dus kan je al een probleem hebben.

De reden dat het bij TCP/IP werkt (ieder pakketje bevat bijvoorbeeld een getalletje waarin de grootte van het pakket staat) dan is dat niet zo'n probleem omdat afgesproken is in welk formaat dat getal verstuurd wordt en zal de TCP/IP stack dat allemaal netjes centraal voor je afhandelen.

Als je echter deze informatie in XML gaat stoppen, dan is dat meteen een stuk lastiger. Want op platform x wordt een BCD gebruikt, en op platform Y wordt unsigned byte gebruikt. (en dus heb je op applicatie niveau het probleem dat het omgezet zal moeten worden)

Kijk maar naar de meest gebruikte communicatie protocollen, daar wordt vaak plain text gebruikt. (denk aan HTTP, SMPT, etc) En dat is niet voor niets....

[Olaf van der Spek]

waardoor de uitwisselbaarheid van dergelijke binaire bestanden een probleem op zou kunnen leveren.

TCP/IP werkt ook prima op die platformen, dus waarom zou XML een probleem vormen?

[chewie]

@JeroenV:

De reden dat het bij TCP/IP werkt dan is dat niet zo'n probleem omdat afgesproken is in welk formaat dat getal verstuurd wordt....

Precies, en over die afspraken, daar gaat dit bericht over. Ze zijn niet van plan om een plain text bericht simpelweg naar binaire data om te zetten maar om een nieuwe standaard neer te zetten voor binaire XML. Afspraken over cijfers en hoe de binaire data er precies uit moet zien en geinterpreteerd dient te worden maken daar natuurlijk deel van uit, dat lijkt me duidelijk.

[VisionMaster]

@ Jeroen V.

Uhm ... Als je het in XML stop dan is het wel lastiger dat je op applicatie niveau het zal moeten oplossen, maar das het hele idee van XML. Dat is dat je los van de architectuur van je machine alles kan doen. Dus dat je pltform onafhankelijk te werk kan gaan met XML.

HTTP en SMTP is prima in plaintext, maar ik gebruik toch liever SSMTP op mijn werk (soms ben ik wat paranoia). De eerste S staat voor secure en dan wordt je lijn versleuteld met een session key. Erg handig voor mensen zoals ik die de Plaintext toepassing van SMTP niet zo geslaagd vinden. Er is in dit geval wel een leuke overhead die erbij komt, omdat de SMTP server onderhuids nog steeds de normale SMTP commando's ontvangt en interpreteerd

[_Thanatos_]

Zeg, ooit gehoord van schema's? Daarmee kun je prima definiëren wat hoe waar moet komen. Dus in binary XML zal ook binary schema's moeten worden opgenomen die definiëren hoe (bijv) getallen eruit zien. Als er bij een bXML geen schema zit, dan is het dus tekst, en dat gaat altijd goed.

[Verwijderd]

En bovenin het document stop jede meta data van een XML file. Dus is het unsigned etc..

[Verwijderd]

Niet iedere TCP/IP stack of TCP/IP gerelateerde protcollen werken goed op ieder platform.

Ter voorbeeld: VLAN tagging met RTL8169 kaarten op big endian machines (big endian MIPS, PowerPC, etc) werkt onder Linux pas sinds versie 2.6.10 ofzo. Dit kwam omdat de byteorder die aan het VLAN gegeven werd verkeerd om was, oftewel: je kist hing in het verkeerde VLAN, ookal gaf ifconfig het goed aan.

Binaire presentaties zijn waarschijnlijk wel sneller, maar op sommige architecturen moeten workarounds gebruikt worden (zoals big en little endian bijvoorbeeld).

[BartOtten]

Sneller = minder rekenkracht nodig = zuiniger.

[Madcat]

ja dat zie je inderdaad helemaal verkeerd.
XML maar ook PHP moeten "geinterpeteerd" worden, wat dus betekend dat er een parser overheen geggooit moet worden wat dus tijd en rekenkracht kost.

een vriend van me heeft php eens "gecompiled" en heeft met zijn code al 10% winst gehaald.. maar het kan echt drastisch oplopen als er speciale gevallen vaak worden gebruikt.

edit:
hier een benchmark van een php "compiler"
http://www.roadsend.com/home/index.php?pageID=benchmarks

[Jeroen V]

Het is niet gecompileerd o.i.d. het is binaire data, dat is heel iets anders.

Als je nu binaire data met XML wilt versturen, dan zal je eerst die data om moeten zetten naar bv een Base64 string voordat die met XML verstuurd kan worden, na ontvangst moet de Base64 string weer naar binaire data omgezet worden. Hetzelfde met bijvoorbeeld een int of float (of wat voor waardetype dan ook) Eerst zal de waarde omgezet moeten worden naar een string, en dan pas kan hij verstuurd worden. Logisch dat dergelijke conversies niet meer nodig zijn indien er direct binaire code verstuurd kan worden.

Dus het wordt om twee redenen sneller, ten eerste is binaire data altijd groter als je het als plain text wilt versturen, en de verzender en ontvanger zullen het moeten converteren naar het waardetype waarmee je zult willen werken.

XML is in principe plain text, dat is de kracht van XML, dus van een wachtwoord voorzienkan dus niet. Wel kan je gebruik maken van een SOAP extension (als je gebruik maakt van bijvoorbeeld web services) die de encryptie voor je regelt.

[VisionMaster]

Hey kijk toch nog iemand die de plank niet zo hard misslaat, sorry, maar ben verontwaardigd dat anderen deze conversie problemen niet direct aan hebben gepakt in hun reply's

W3C is niet met harddisk opslag bezig maar met standaarden voor protocollen en andere afspraken daar omheen. Dit artikel heeft volgens mij vooral met de Web Services ontwikkelingen te maken.

In het begin werd een data blob geconverteerd naar XML (base64 meestal) en dit geeft een enorme overhead. Daarna werd het weer omgezet in de datapakketten voor je netwerktransportlagen. Dus uberhaupt om het weg te krijgen heb je niet alleen partitionering, maar ook conversies nodig.
Als je een Gigabyte wilt overzenden (ooit gedaan door meneer Snelling van Fujitsu die met WSRF bezig is) dan ben je daar erg lang mee bezig en gaat het in de dagen lopen...

Een idee was om binair een data blob als een SOAP extensie te versturen in zijn onveranderde binaire vorm, seperaat van het lapje XML dat overgestuurd wordt.

Nu is het weer het idee dat XML overgezet moet worden naar een totaal binair protocol. Ik denk dat dat niet gaat gebeuren, omdat er te veel veranderingen moeten plaats vinden om je hier aan te houden EN XML is bij uitstek een leuke taal die voor onze simpele human brains (snel) te lezen is. Ook al staat er een hoop rubish in in verband met het schema dat je aanhoudt in je velletje XML.

[Johnny]

OpenOffice bestanden zijn ook gewoon een verzameling XML bestanden met stylesheets die worden ingepakt in een binair formaat vergelijkbaar met een ZIP bestand, daar kan dus ook compressie en een wachtwoord op. Alleen het openen gaat weer wat langzamer.

[Patrickske]

Ik kan me vergissen maar:
Microsoft, OpenOffice.org en andere software makers zijn bezig met hun eigen versie van een binaire XML. Misschien wil het W3C ervoor proberen te zorgen dat op deze manier er toch een standaard ontstaat.

Over die snelheidswinst twijfel ik een beetje trouwens. Een binaire XML zal zeker een stuk kleiner zijn, maar het vergt op haar beurt weer nabewerking om de info weer leesbaar te maken voor mensen ogen.
Ik meen dat OpenOffice.org's binaire XML niet meer of minder is dan een ingepakte XML (door middel van een ZIP-achtig algoritme)

[BartOtten]

Voorbeeldje (ietsjes mank maar toch):

10.000 x een pagina parsen voor 10.000 bezoekers

of

1x parsen voor invoer en evt. een keer terug voor een wijziging.

Spaar jer toch al heel wat parsingtijd en energie. Alles wat je bij Tweakers.net tikt zal ook voor een deel geparsed de DB ingaan. Dus omgezette tags enzo. Als je edit rekent ie weer terug.

[Boogerschmidt]

Dit is waarschijnlijk bedoeld voor pagina's die niet bijster veel interessante code bevatten, en vooral snel geladen moeten worden.

Ik weet niet of dit mogelijk is, maar uit die binaire code zou toch op een of andere manier weer 'leesbare' XML te parsen moeten zijn?

[Remus]

XML wordt niet alleen gebruikt voor informatie die door mensen gelezen hoeft te worden. In veel situaties wordt het gebruikt om informatie uit te wisselen tussen systemen (waar voorheen een proprietary binair formaat voor wordt gebruikt). Dit gaat ook zeker niet om gezipte XML zoals OO.org doet.

[dasiro]

Edit: waarschijnlijk wil de industrie dit omdat binaire informatie ook makkelijker beveiligd kan worden, en wordt het ook mogelijk om xml bestanden van een password te voorzien

uiteindelijk wordt alles binair opgeslagen en kan het dus ook op dezelfde manier vergrendeld worden

[packman]

Bij het inlezen van een XML bestand moet je parser gaan zoeken naar een start-tag die "<" is, dat wil dus zeggen, een hoop karaktertjes gaan vergelijken.dan moet hij de naam extracten, die gedelimit is met een spatie of een > als er geen argumenten zijn bij die tag. Dan moet hij alle argumenten als text inlezen, parameter en waarde splitsen op een '=' teken, tot hij een "/>" of ">" tegenkomt. En dan hebben we enkel nog maar de opening tag. Dit vergt een pak meer tijd dan gewoon een binair formaat te lezen en te schrijven, waar de lengtes van velden snel en makkelijk te lezen zijn.

Bij een binair formaat moet je geen whitespace skippen, cijfers zijn gewoon binair opgeslagen, wat wil zeggen fixed-length 2 of 4 bytes, zoeken naar het einde, geen parsing en controle of het wel numeriek is, ... Voor een string-waardes of gewoon binaire data zet je er gewoon voor hoe lang ze is, wat 1, 2 of 4 bytes overhead heeft afhankelijk wat nodig is - maar een pak sneller is omdat je geen start en end-string quotes gaan zoeken, escaping of ander conversie-schema gaan toepassen, geen base64 decoding, ... wat het allemaal enorm vertraagt. Daardoor heb je een pak minder memory nodig voor het parsen, en kan je library in een taal zoals C(++) direct gaan mappen met pointertjes in je file-structuur na een snelle tree-parsing gedaan te hebben, en moet je de data niet inlezen, parsen en kopieren in memory. Enkel endianess wordt dan een probleem, maar ik veronderstel dat men dan gewoon Big-Endian gaat gebruiken voor numerieke gegevens op te slagen, vermits dit overal ongeveer de standaard is (buiten op pc natuurlijk - intel moest weer eens het anders doen)

Nog een commonly-used techniek bij XML die vertraagt is deze stream-zippen en unzippen voor dit verstuurt wordt over een netwerk, dus komt daar nog eens het comprimeren en decomprimeren bij, wat bij een binair formaat nog altijd mogelijk is (en levert in veel gevallen nog altijd serieus wat op), maar het zal zo hard niet meer nodig zijn. Veel XML-files bevatten zo een hoop white-spaces om het leesbaar te maken dat je daar enorm veel bloat mee creeert.

Ik heb het al gezien, een klant die een export vraagt van bepaalde gegevens van een systeem, en zou dit liefst in XML zien (da's waar het voor gemaakt is), wordt er intern in het bedrijf beslist (gepusht door een XML-freak) om het hele interne protocol van hun project dan maar ineens om te zetten naar een XML-formaat, voor "de toekomst". Voordien was dit een bliksemsnel binair formaat dat deed wat het moest doen, en waar al lang geen problemen meer mee waren. De implementatie is vrij vlot gegaan, en enkele maanden later had men dit XML-protocol draaiten op een test-systeem, waar weinig problemen mee waren qua functionaliteit. In test werden er gewoon geen problemen gevonden - tot men het systeem een "real world" stresstest liet ondergaan. Het ding ging op zijn knieen bij 600/700 connecties, waar dit voordien makkelijk 10 keer zoveel haalde. Het probleem was, de klant had wel degelijk 5 keer zoveel connecties nodig, zo'n 3000... Men had "geluk" dat de library die men gebruikte XML-accelerators ondersteunde, wat betekende dat je effe een PCI-kaartje bij in je bak kon rammen om je XML-parsing te versnellen. Alleen al het feit dat dit bestaat vind ik vrij surrealistisch - hardware-acceleratie voor een data/file-formaat? Dat je dit voor een low-level protocol hebt zoals TCP/IP kan ik geloven, vermits quasi elke pc op deze aardbol dit gebruikt, en dit zeer low-level is, maar XML???

Ander geluk was had een van de andere developers hard genoeg zijn wil doorgedrukt en het protocol in een virtualisatie-layer te steken, waardoor men kon kiezen tussen XML en het "oude" protocol. Voor de klant heeft men uiteindelijk gewoon een stomme export geschreven - wa 2 dagen heeft geduurt incl testing - en da werkte gewoon...

XML is handig als "data-exchange" - maar nie voor netwerk-protocols zoals SOAP en andere zaken waar het misbruikt voor wordt, dat is gewoon te belachelijk om los te lopen. Zolang je server geen XML-parsing moet doen, enkel de client - geen probleem, die hebben meestal toch CPU-power teveel tegenwoordig, maar op server zware XML-parsing doen heeft nie veel positieve effecten op performance...

[Chesta]

hun zeggen dat het sneller is dus zal het wel zo zijn, maar nog meer voordelen?

[AxiMaxi]

Als men nu zou besluiten om een 'snellere' standaard te gaan ontwikkelen zou het namelijk makkelijk drie jaar kunnen duren voor versie 1.0 af is. Tegen die tijd zal ook normale XML veel sneller zijn, puur vanwege de betere hardware en snellere (draadloze) netwerken die tegen die tijd beschikbaar zijn.

Lekkere cirkel redenatie. Hoe snel je netwerk / hardware / verbinding ook is: een binaire versie zal altijd sneller zijn dan een tekst versie!

[Verwijderd]

Het zag er even naar uit dat het Windows platform eindelijk verlost zou raken van die waardeloze binaire bestandformaten. XML was de toekomst. Wat UNIX gebruikers al decennia wisten drong nu ook in Redmond door: Bestanden in tekst formaat kan je verrassend eenvoudig en direct genereren en manipuleren via standaard commandline en home-grown scripts. Automatisch brieven en andere documenten genereren doe je gewoon met je eigen scripts, niks geen speciale software nodig. Na al die jaren nog steeds een briljant concept.

Wellicht wordt de tekst-formaat revolutie op Windows alsnog afgewend. Gelukkig hebben altijd onze goeie ouwe UNIX OS-sen nog.

[-=bas=-]

En maar zeuren dat windows zo traag is....

Je vergeet geloof ik dat je al je data moet parsen en interpreteren terwijl je bij binaire data direct je gegevens kan gebruiken.

Schaf verder ook maar een paar extra harde schijven aan want uiteraard zijn binaire bestanden veel efficienter om data in op te slaan dan XML bestanden.

[SuperDre]

Binair is wel ff 10 keer beter dan platte tekst zoals XML.. Ik wordt juist ziek van al die XML.. Ik koop een snellere computer om er ook sneller mee te kunnen werken, door XML en .NET is diezelfde computer net zo snel als mijn oude 500Mhz PCtje omdat alles eerste geinterpreteerd/gecompileerd moet worden..
Nee geef mij maar binair zodat je dat gezever niet hebt.. En ik heb ook liever niet dat iedereen zo simpel een XML bestand kan aanpassen..

[nika]

Kijk, dit lijkt me een goed ontwikkeling! Eventueel combineren met compressie.

Probleem met XML vind ik altijd de ontzettende berg overhead. Stel dat je bovenstaand bericht gewoon als een binaire array zou versturen. Dat scheelt een hoop dataverkeer op het net.

[Verwijderd]

Wel eens gehoord van compressie?

Oh ja, ik zie het.

Ik denk dat een gecomprimeerde tekst-formaat XML ongeveer even groot zal zijn als een gecomprimeerde binary-format XML. Beide bevatten namelijk dezelfde informatiepatronen. Hier even aangenomen dat je een goeie compressor gebruikt die bijna witte ruis produceert.

[Verwijderd]

Er is voor SyncML al zo'n binaire standaard voor XML afgesproken, de zogenaamde Wireless binary (wb)xml. Deze standaard wordt door bijvoorbeeld veel telefoons en andere mobiele apparaten al ondersteund, waarom deze niet uitbreiden?

[joho]

XML word langzamerhand steeds wijder verspreid.
Ook embedded devices; elke machine (koffiezetter), die met andere machines praat, wil wel over naar de universele standaard die XML heet, maar als je apparaat vaak of elke milliseconde informatie moet uitwisselen kies je nu nog ,vanwege die snelheidsaspecten, een eigen bericht formaat.
Dus een standaard binaire XML oplossing zou hier een uitkomst bieden.

[Zyphrax]

Binaire XML?

Dat lijkt me dan gewoon een XML document en dan gecompressed? Ofwel dat je altijd voor het verwerken van het document de stap maakt naar readable XML. Daarmee kan het nooit sneller zijn dan readable XML omdat je altijd eerst naar readable XML moet?

Anders is het toch geen XML meer?!

[packman]

Waarom zou dat eerst naar readable XML moeten? Je moet gewoon kunnen zeggen tegen je XML library wat hij moet genereren. Ofwel leesbaar, ofwel binair. Dit zou ideaal zijn als dit transparant kon, dan kan je voor het debuggen de "plain-text" versie gebruiken, en voor productie-doeleinden het binaire formaat, wat een pak compacter en sneller gaat zijn.

Programmatjes die je binaire XML dan naar text en omgekeerd omvormen zouden dan heel handige tools zijn, maar heel veel XML op dit ogenblik is gegenereerd door software, niet handmatig ingetypt. Data waar mensen rechtstreeks in moeten gaan editeren zullen best in gewone XML opgeslagen worden, wat eventueel geconverteerd kan worden als dit over netwerk moet verstuurd worden....

[Plekuz]

Voor een computer maakt het niks uit of ie nou character bytes moet interpreteren naar interne logica of binaire bytes. Met het juiste algoritme zal er niet of nauwelijks snelheidsverschil zijn. In beide gevallen moet het naar eentjes en nulletjes.

Ik zie het wel zitten, want er zijn nu al verschillende bedrijven die een maximum stellen aan de grootte van het aan te leveren XML, terwijl je er gemakkelijk door alle overhead van de tags overheen gaat.

[Varienaja]

Ik kan me voorstellen dat je bij het opslaan van een document in een tekstverwerker binaire XML erg handig vind. Immers: de plaatjes zijn sowieso niet human-readable in tekst vorm.

Voor alle andere gebruiken van XML zou ik het graag verbieden om binaire opslag te gebruiken. Dan is het namelijk geen bruikbare xml meer, je kan dan niet meer met notepad een correctie aanbrengen.

[Vorlon]

Eeh, een document in een tekstverwerker?? Dat vind ik persoonlijk nu wel het slechtste voorbeeld.

Plaatjes kan je toch gewoon linken lijkt me? Dan heb je een platte tekstfile en daarbij een opmaak. Dus ala onderwaterscherm van WP zegmaar. (shit, ik wordt oud )

[Technocratia571]

De motivatie lijkt me achterhaald. De snelheid van mobiele apparaten is nu al ruim voldoende voor XML parsing. XML is snel genoeg te parsen omdat het geen tolerantie kent zoals HTML, dat met de helft van de code nog steeds redelijk kan functioneren. Neem simpelweg het verschil in rendersnelheid tussen een HTML-website en een XML-versie, of XHTML wat aan dezelfde strenge eisen als XML moet voldoen (maar waarvoor alleen de Mozilla's ondersteuning bieden).

Bandbreedteproblemen zie ik ook niet. Hedendaagse browsers ondersteunen transparante gzip compressie en dat vereist misschien wel nog meer processorkracht maar naar mijn mening hebben apparaten daar toch al genoeg van.

Voor wie het wil vergelijken: open eerst eens http://www.dutchcowboys.nl open dan eens http://www.dutchcowboys.nl/?xhtml=1 Die extra parameter schakelt content-type application/xhtml+xml in in plaats van text/html (voor browsers die dat ondersteunen) samen met transparante gzip compressie.
Het systeem is nog niet perfect xhtml-proof, er kan soms onvolledige code voorkomen in de posts waardoor xml-compliancy wordt gebroken.

[Superstoned]

je hebt gelijk, xhtml is sneller (Konqueror/KDE3.4/Linux2.6.11/SuSE9.2).

[Frank-L]

Ik begrijp al nooit waarom de close-tag in xml niet compacter kan. In feite zou bijvoorbeeld </> als universele close-tag kunnen worden gebruikt. Het is namelijk altijd eenduidig bij welke open-tag de close-tag hoort.

[Verwijderd]

Even HTML als voorbeeld:
<table>
<tr>
<td>
<b>Een helehoop tags</>die voor een compiler/parser goed te lezen zijn. <br />Maar maak even een inspring fout, of heb een helehoop <a href="javascript:void(0);">HTML tussen tags, en je bent de weg kwijt.</>
</>
<td> bleem </>
</>
</>