Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 28 reacties
Bron: News.com, submitter: Wouter Tinus

News.com vertelt dat de recent uitgebracht XML 1.1 specificatie niet door iedereen met open armen werd ontvangen. Het W3C heeft een voorstel voor de standaard deze week openbaar gemaakt, en men heeft ongeveer vier maanden de tijd om aanvullingen of verbeteringen te suggereren voor het document het stempel "final" zal krijgen. De belangrijkste verbeteringen in versie 1.1 ten opzichte van 1.0 liggen op het gebied van Unicode ondersteuning. Dit is nodig om bijvoorbeeld met Russische of Japanse tekens te werken, maar ook voor bepaalde Westerse tekens als en . Het eerste commentaar dook echter al snel op. De schoen wringt bij een teken dat alleen door IBM gebruikt wordt om een nieuwe regel aan te geven. Het bedrijf wordt er van beschuldigd zijn macht te misbruiken om een standaard erdoor te duwen. Het opnemen van het IBM-newline karakter zou betekenen dat een deel van de huidige XML 1.0 documenten kapot zou gaan met het invoeren van versie 1.1. IBM meent dat programma's die met XML werken dan maar de versie van de gebruikte standaard moeten controleren:

XML "IBM mostly grew out of their anti-competitive monopolistic tendencies over the last thirty years (with a large dose of assistance from the U.S. government)," reads an editorial on the XML news site Cafe con Leche that has circulated within the W3C's own XML 1.1 discussion forum.

"However, there are still some legacy issues relating to their attempt to dictate standards to the rest of the industry, and this is one of them. Now rather than fixing their own broken mainframe text-editing software, they want everyone else on the planet to change their software so IBM doesn't have to," it said.
Moderatie-faq Wijzig weergave

Reacties (28)

Het probleem is dus dat veel van de huidige parsers 'op hun bek' zullen gaan als er tekens voorkomen die wel scheidingstekens (zouden moeten) zijn, maar die niet als zodanig wordt herkend. Een XML 1.0 parser kan dus bijvoorbeeld een foutmelding geven als er een XML 1.1 document met IBM newline characters wordt geparset.

Lees hier trouwens meer over de [NEL] character:
http://www.w3.org/TR/2001/NOTE-newline-20010314

Het is vrij onwaarschijnlijk dat er gewone XML 1.0 documenten 'kapot gaan', aangezien teken #x85 toch niet zo gauw gebruikt werd, lijkt me.

Ik zie het probleem eerder bij de oude parsers die het nieuwe formaat niet goed zullen herkennen. Ook mijn eigen XML parser (in java) zou dit namelijk niet begrijpen.

Er is echter maar een zeer kleine aanpassing van de software nodig. Ik denk dat het probleem echt enorm overdreven wordt, en het was al lang geleden bekend dat dit zou gebeuren.
hoe breder kwa standaard hoe beter

echter is het jammer dat het niet backwardscompatible zou zijn

IBM meent dat programma's die met XML werken dan maar de versie van de gebruikte standaard moeten controleren:

tja das niet zo makkelijk natuurlijk. ik weet niet in hoeverre xml al imbedded wordt gebruikt en hoeveel bedrijven er al mee werken, maar het is natuurlijk een tactiek die ze van microsoft hebben afgekeken...

het is natuurlijk slim om te zorgen dat anderen hun software aan moeten passen ipv dat je het zelf moet doen, scheelt je toch weer een aantal programmeurs voor een periode aan het werk hebben.
De vraag is: Hoe graag wil de XML community de data van deze IBM systemen delen?

Ik denk: Hoe meer hoe beter.

Dus als het niet te moeilijk te intergreren is moet dat vooral gebeuren. (d.w.z: wel karakter gaat verloren en hoeveel impact heeft dat?)
Het zou me niets verbazen als IBM zijn zin krijgt. Tenslotte is een standaard end-of-line char in XML ook de LF en niet de CRLF ... zoals dat op een Microsoft OS het geval is. Unix / Linux gebruikers zijn hier natuurlijk blij mee en hier zijn ook de XML docs naar gevormd. Sterker nog, de XML editors die draaien op Windows zien in de LF ook een nieuwe regel beginnen. Dit wijzigen maakt veel in productie zijnde docs kapot.

(Al heeft de gemiddelde XML developer natuurlijk een nette XSD of DTD die de inkomende XML stream valideert voordat de parser deze naar de app stuurt.)
Dat [NEL] als newline character gebruikt gaat worden is helemaal niet zo vreemd, het is nl de newline charchacter van Unicode 3.0, waar XML 1.1 support voor bied. Of het goed is, is een andere vraag.
Het is natuurlijk belachelijk dat door een unicode teken de hele XML struktuur over z'n nek gaat omdat het niet backwards compatible is. Dan ligt half internet binnen de korste keren plat. (leuk he, overdrijven)

Laat ze die code erin houden maar dat je die expliciet AAN moet zetten als je het wil gebruiken. Dan hoeft IBM maar n parameter extra tijdens het opstarten van hun programma's mee te geven. Of ze bouwen het in hun eigen JVM.
Ik denk dat de backwards compatibility er ook niet is als dat tekentje er niet in zit, aangezien de rest van unicode er wel bij zit, die snappen de huidige 1.0 XML parsers natuurlijk ook niet.

Ik denk dat het er vooral om gaat dat de 1.1 XML standaard een standaard is, wat dus inhoud dat een of ander tekentje van IBM daar niet in thuis hoort.
Ik vind het van weinig professionaliteit getuigen wanneer je niet de XML versie meegeeft. dus alleen de n00bs (ik dus eigenlijk ook ;)) krijgen hier problemen mee.
Maar daar gat het hier niet over. IBM wil hier iets wat niet standaard is, tot standaard verheffen. Ik vind dat dat niet kan.
Zoals al door anderen gezegd is: de afhandeling van new lines is ook niet standaard, die is anders voor Windows dan voor Unix bijvoorbeeld en er is vast geen ISO standaard die zegt dat een new line op Windows CrLf moet zijn en op Unix alleen Lf.

Aangezien de huidige parsers helemaal geen 1.1 documenten MOGEN parsen zie ik verder geen probleem (als men aanneemt dat documenten zonder versie als 1.0 worden gezien) als IBM probeert om "hun" new line ook op te laten in de XML standaard.

Een standaard is maar een afspraak en veel standaarden beginnen hun leven als een idee/implementatie bij een of ander bedrijf of bij iemand op een zolderkamertje. Het wordt een standaard op het moment dat zo'n idee door een standaard organisatie wordt overgenomen. Zo kan het ook heel makkelijk met dit IBM voorstel gaan.
Dit heeft natuurlijk weinig te maken met de apparatuur... Idee is dat er geen standaard kan opgezet worden als de te ondersteunen tekens niet duidelijk zijn. Helemaal als je het hebt over een newline karakter...

edit:

had gepost moeten worden als reactie op user.. is helaas fout gegaan.
Naar mijn weten is er nooit een duidelijk character voor een Newline geweest.

\n
\r
\CHR10
\CHR13
\vbcrlf
\vbNewline

en dan loopt het nog door elkaar qua hardware ook :)
\n = chr(10) = vbNewLine = vbLf
\r = chr(13) = vbCr
\r\n = chr(10) + chr(13) = vbCrLf

En het is op zich best duidelijk als je je tot 1 OS beperkt:
Windows : Cr Lf
Unix : Lf
Anderen : ??
MAC: CR (\r) of LF CR (\n\r)
Wat ik eigenlijk hiervan vind, is dat het eigenlijk voornamelijk behoorlijk soepel is verlopen, die standaardisering. In het kader van Webservices zeg maar. SOAP is een standaard en voor XML ook. Nu is er even een kleine glitsch, maar ik denk dat ze uiteindelijk redelijk snel tot een standaardisatie komen, in tegenstelling tot andere segmenten van dezelfde markt.
Roep niet te hard dat SOAP een standaard is voor je ermee gewerkt hebt hoor. SOAP is bijna nog niet te gebruiken als je cross platform wilt werken. Er zijn erg veel verschillende versies/implementaties en die werken nog niet soepel samen. .NET komt nog het verst maar ga vooral niet probeer via bijv. IBM software (WSAD) een webservice te maken en hopen dat je die dan via .NET kunt benaderen. Eerst was er Apache Soap (gebaseerd op IBM Soap4J), dat is overgegaan naar Axis (en volkomen veranderd). Bijna iedereen gebruikt nog Apache Soap en daar zitten ernstige restricties in: geen arrays, en samengestelde en zelfgedefinieerde types, niet mixen van int en Integer etc. etc. etc. Het zal nog geruime tijd duren voor het een goed bruikbare standaard wordt. Er wordt nu hard gewerkt aan een nieuwe Soap standaard waar ook encryption, compression, authentication etc. inzit. Pas als dat geimplementeerd is EN over inzit/gebruikt wordt wordt het leuk...
Ik ben benieuwd wat de reactie van IBM is. Het artikel is NOGAL negatief over IBM, dat toch allerlei standaarden heeft bedacht en weggegeven (XML, SGML en nog veel meer).

Ter overweging: 70% van ALLE data wereldwijd staat opgeslagen in een mainframe. Als de nieuwe XML-versie het onmogelijk maakt om die data te ontsluiten, is dat geen vooruitgang.
Of IBM dit probleem ook intern zou kunnen oplossen, kan ik op dit moment niet beoordelen. Maar eenvoudig is het vast niet.
dat toch allerlei standaarden heeft bedacht en weggegeven (XML, SGML en nog veel meer).

Voor de helft goed. SGML is idd ontwikkelt door IBM (in '69) ... maar XML zeker niet. Sterker nog, IBM maakte officieel niet eens deel uit van het eerste W3C team dat de 1.0 XML recommendation schreef. Het team had wel wat ex-IBM mensen, maar officieel bleef IBM er buiten.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True