W3C wil mobiele XML-standaard

Het W3C heeft een voorstel gedaan om een compactere vorm van xml tot standaard te verheffen. De standaard, exi, moet features van xml beter beschikbaar maken voor draagbare apparaten als telefoons, camera's en printers.

De compacte xml-standaard is al langer in ontwikkeling, maar is deze week in zijn 1.0-versie voorgesteld als standaard door W3C, de organisatie voor webstandaarden. De compacte variant op xml moet het dataverkeer en geheugengebruik verminderen ten opzichte van xml, terwijl de features grotendeels behouden blijven. Daardoor wordt gebruik van xml-features mogelijk op apparaten met gelimiteerde bandbreedte of beperkte hardware, zoals telefoons en camera's.

Fabrikant Canon is blij met de voorgestelde standaard, schrijft Infoworld. "Wij verwachten dat exi ons in staat stelt overtuigende webdiensten te laten zien op producten als printers en camera's." De standaard moet overweg kunnen met bestaande xml-toepassingen, zo staat in het voorstel te lezen. Het is nog onduidelijk wanneer exi wordt toegepast in elektronica.

Reacties (38)

[YopY]

XML wordt, imho, tegenwoordig veel te veel en te gemakkelijk gebruikt om gegevens tussen twee systemen door te geven. Het grote voordeel is dat het zowel door mensen als door programma's te lezen is, maar als je even twee seconden nadenkt: 99% van de tijd doen computers dat, en als je nagaat hoeveel overhead er in XML zit...

Het lijkt erop dat deze standaard een poging is om deze overhead flink te verminderen danwel in zijn geheel weg te halen. Deze standaard geeft een manier aan om een XML document door te geven aan een gebruiker door middel van een EXI stream, waarbij een XML document omgezet wordt in een reeks 'events' - Document start, Element start, karakters komen, etc.

Ik heb de standaard nog niet goed genoeg bekeken om na te kunnen gaan hoeveel het nu daadwerkelijk bespaart. Alhoewel, beetje zoeken kom je op deze evaluatiepagina terecht. Het lijkt erop dat je een EXI stream met de bestaande XML API's uit kunt lezen (dus weinig aanpassingen nodig aan code om EXI uit te lezen ipv XML), en dat, als je EXI ipv XML naar een Java SAX-parser stuurt, dit 14 maal zo snel verwerkt kan worden.

edit: Relevant plaatje. deze grafiek toont het verschil tussen 'compactness' tussen XML (rode lijn, 100%), GZipped-XML (roze lijn, Gzip maakt het document soms zelfs groter), en XML documenten als EXI geëncodeerd. Dus qua grootte kan een XML document, afhankelijk van het document natuurlijk, 99% bespaard worden qua doorgegeven bits. In het slechtste (getestte) geval is de besparing alsnog 40%, wat ietsje beter is dan GZip. Maar als je de grafiek bekijkt, EXI bespaart altijd meer bits dan Gzipped XML, en wat belangrijker is, de besparing is constant, itt Gzipped XML dat nogal inconsistent is. Dat is ook logisch, aangezien gzip werkt op tekst en niet geoptimaliseerd is voor XML.

[Reactie gewijzigd door YopY op 23 juli 2024 12:59]

[SvMp]

Ik kan mij daar niets bij voorstellen. XML heeft net zo veel features als het doel waarvoor het wordt gebruikt. Je zou iets met de lengte van de tags kunnen doen, maar comprimeren lijkt mij effectiever, en daar is geen nieuwe standaard voor nodig.

[_beevee_]

comprimeren met bijvoorbeeld GZIP heeft als nadeel dat je het bestand dan eerst in z'n geheel moet ontvangen, in z'n geheel moet decomprimeren én als een grote tree moet parsen. Bij EXI gaat dat in blokjes. Dus je ontvangt een blokje, decompirmeert het, gebruikt het etc.
Dus je kan veel sneller met de ontvangen (stream) data aan de slag en hebt maar weinig geheugen nodig.

[Verwijderd]

Euhm, JSON?

[Fuzzillogic]

Euhm, nee? Voor XML zijn veel meer belangrijke tools beschikbaar dan voor JSON. Wat XML zo krachtig maakt is niet zozeer "XML", maar de hele toolset in de vorm van XSLT, SOAP, XQuery, etc etc.

Daarnaast kun je in JSON iets als <list><foo /><bar /><foo /></list> veel minder handig uitdrukken, met nog veel meer overhead dan standaard XML al heeft.

JSON heeft zeker zijn waarde, maar zoals zo vaak in de webtech is het niet perse beter dan wat ervoor was. (En als developer met veel webtech-ervaring zeg ik zelfs: integendeel)

[elmuerte]

Snapt JSON namespaces dan?

[_Thanatos_]

Nee, maar hoe precies is dat boeiend?

[YopY]

Zodra je niet-triviale gegevens over moet sturen (dus voorbij het niveau van 'berichtjeuh') wordt dat boeiend.

[_Thanatos_]

Mja ach. Als je het écht wilt... niets houdt je tegen om een dubbelepunt in een veldnaam in JSON te gebruiken.

[ATS]

Weet iemand zo wat de grote verschillen ten opzichte van XML zijn, technisch gesproken? Wordt bijvoorbeeld de verbose closing tag vervangen door iets korts? Een korte samenvatting zou leuk zijn; op wikipedia zie ik weinig meer dan dat het een binair formaat is, en dat een compressie op basis van het gebruikte XML-Schema mogelijk is.

[Reactie gewijzigd door ATS op 23 juli 2024 12:59]

[YopY]

http://www.w3.org/TR/exi/#principles geeft wel een duidelijk beeld. Het lijkt op een soort van encryptie, waarbij een XML document omgezet wordt in een set 'events' die via een stream doorgegeven worden aan gebruikers. Events, in dezen, zullen wel bekend zijn als je de SAX-API Dus in plaats van 7 bytes voor een XML open-tag als <nieuws>, krijg je nu een 'bericht' binnen verpakt in een paar bytes die aangeeft dat er een 'nieuws'-tag geopend wordt.

Maar dat kan ik misinterpreteren. Het is geen 'XML Lite' versie, om zo maar te zeggen, maar een nieuwe, compactere manier om de gegevens daarin door te geven.

Op zich wel interresant om even in te verdiepen.

[_beevee_]

Enkele voordelen: zeer goede compressie zonder de noodzaak om eerst het GEHELE bestand te moeten ontvangen en decompromeren (wat bij GZIP wel nodig is). De elementen kunnen dus tijdens het binnen streamen gedecomprimeerd en alvast gebruikt worden (dus minder geheugen nodig en sneller beschikbaar). Het event gebaseerde parsen en indexeren is sneller en vergt minder CPU power dan het traversen van de hele XML tree.

[supermidget]

http://www.w3.org/TR/exi/#EXICookie

The four byte field consists of four characters " $ " , " E ", " X " and " I " in that order, each represented as an ASCII octet, as follows.

[Verwijderd]

Ik vind toch dat mobiele browsers alles moeten ondersteunen

[MrSnowflake]

Uhm, hoe vaak wordt xml echt gebruikt in browsers? Deze standaard heeft vrij weinig met browsers te maken. Browsers gebruiken (voornamelijk) html en niet xml of exi.

[latka]

HTML is een slap aftreksel van XML, ze zijn ontzettend verwant (XHTML kun je ook gewoon door een XML parser trekken). Ik denk echter niet dat men een HTML variant gebaseerd op EXI zal maken. Datatransport via gzip compressie is al jarenlang standaard en levert de bandbreedte besparing al op. De snelheid van mobiele apparaten gaat ook al in de 100'en Mhz dus de traagheid van XML valt dan niet op.

[YopY]

Bandbreedtebesparing, echter maar tot zover en afhankelijk van de inhoud. GZip veroorzaakt ook extra overhead, evenals het vertalen van de HTML / XML code naar een interne datastructuur (DOM). Met EXI wordt zowel de GZip compressie als de conversieslag(en) overbodig, blijkbaar.

[Ruud v A]

Het is andersom, XML is afgeleid van HTML en vervolgens is XHTML gebouwd op XML.

[Herko_ter_Horst]

Zeker niet. HTML en XML zijn beide afgeleid van SGML. XHTML is een afgeleide van HTML die voldoet aan de XML standaard.

[mu-sick]

Genoeg 'html'-website die afhankelijk zijn van XML. Daarnaast is XML ideaal voor bijvoorbeeld (online) Apps.

[Niemand_Anders]

Inmiddels zijn er al beter alternatieven voor data overdracht zoals JSON of ProtocolBuffers. Applicaties moeten van te voren weten welke data ze ontvangen omdat ze anders niet verwerkt kunnen worden en in de basis heeft XML gewoon een grote overhead waardoor het minder geschikt is voor mobiele toepassingen.

Zeker als je beschrijvende elementen gebruikt neemt de overhead al snel toe. Veel andere partijen welke met XML werken laten dan bijvoorbeeld de klinkers weg uit de element namen zoals bijvoorbeeld het geval is in de SEPA specificaties.

Zodra een mobiele applicatie grotere hoeveelheden XML ontvangt, moet deze via SAX worden verwerkt omdat je daarmee het geheugen gebruik beperkt houden. Echter via ik zeer regelmatig dat toch voor DOM verwerking wordt gekozen met als resultaat dat applicaties minder responsive zijn.

Overigens heeft nog geen enkele programmeur mij kunnen overtuigen waarom XML beter geschikt zou zijn voor mobiele applicaties dan JSON..

[Terror]

Eens. Zijn ze snel geneog voor tegenwoordig.

[pontoe]

Ze zijn er snel genoeg voor en ondersteunen het ook zeker. Het probleem is dat je bij mobiele apparatuur al snel met beperkte bandbreedte of een datalimiet zit. Daarom moet je proberen om webtoepassingen zo lichtgewicht mogelijk te houden. Wanneer je een erg groot XML document op de webpagina hebt kan dit voor een flinke verbetering zorgen.

[ruben]

Vergeleken met youtube of flash zal XML niet erg veel uitmaken qua bandbreedte op de huidige telefoonds. Die gaan beter om met websites dan de browsers en hardware van een paar jaar geleden.

Maar voor camera's of andere embedded devices kan ik het me wel voorstellen dat ze lichtere vorm van communicatie willen hebben, en daar is de nieuwe standaard voornamelijk voor.

[SuperDre]

Wat een onzin zeg.. Laat ze maar gewoon oprotten met Yet-another-variant-on-XML, de gemiddelde mobiel die nu op de markt komt is krachtiger (en meer geheugen) dan een gemiddelde PC indertijd van de opkomst/doorbraak van XML.. XML is sowieso een bandbreedte verslindend formaat, maar dat is in het verleden geen probleem geweest, dus waarom nu ineens wel?

[YopY]

Het is geen variant op XML, het is een nieuwe manier om die gegevens rond te sturen. Het lost juist het bandbreedte verslindende gedeelte op van XML, waarbij de grootte van de verzonden gegevens met een factor 6 tot 14 teruggebracht kan worden. (en het ook nog eens sneller verwerkt kan worden, doordat er geen overhead in zit van het vertalen van data van en naar een XML document).

[Reactie gewijzigd door YopY op 23 juli 2024 12:59]

[SuperDre]

tja, waarom zou dat dan alleen voor mobile moeten zijn en niet gewoon de nieuwe XML standaard ansich?

[Freee!!]

De standaard, exi, moet features van xml beter beschikbaar maken voor draagbare apparaten als ... printers.

Sinds wanneer zijn printers draagbare apparaten

[s.stok]

Ja dat vraag ik me ook af, mijn printer allerminst draagbaar

Ik kan 123 niet uit dat document van W3C wijs worden of het nu een vorm is van XML als tekst of binary. Iemand dit weet?

[YopY]

Het is een soort van protocol voor het versturen van de daadwerkelijke gegevens die in een XML document staan.

Zie het zo: Een XML document zoals je die kent is een lap tekst met open- en sluit tags, attributen, etc. EXI is een vervanger daarvoor, die via binaire codes aangeeft aan een gebruiker dat een tag opent, sluit, etc.

[viper-srt10]

Draadloze printer hé

[_Thanatos_]

Draadloze printer? Met accu ofzo?

[arjankoole]

Draadloze printer? Met accu ofzo?

wel eens van mobiele pin gehoord? zit ook een printertje in voor de bon.

[elmuerte]

Al jaren: http://www.google.com/sea...shop%3A1&q=mobile+printer

[Skinkie]

Laten we maar eens met protocol buffers beginnen dan....