🥇XML wordt vrijwel altijd niet zoals bedoeld toegepast

XML is in 1996 uitgevonden. Nog voordat het goed en wel geïntroduceerd was, begonnen mensen echter al verkeerd te begrijpen waarvoor het gebruikt kon worden, en voor de doeleinden waarvoor het aangepast werd, was het niet de beste keuze.

Het is een understatement om te zeggen dat de overgrote meerderheid van de XML-schema's die ik heb gezien, een onterechte of verkeerde toepassing van XML waren. Bovendien duidde zo'n toepassing van XML op een fundamenteel onbegrip van wat XML in essentie is.

XML is een opmaaktaal. Het is geen gegevensformaat.. In de meeste XML-schema's werd dit onderscheid duidelijk niet gemaakt, waardoor XML verward werd met een gegevensformaat, wat uiteindelijk betekende dat de keuze voor XML zelf een fout was, aangezien er in werkelijkheid een gegevensformaat nodig was.

Zonder in detail te treden, is XML het meest geschikt voor het annoteren van tekstblokken met structuren en metadata. Als uw belangrijkste taak niet werkt met een tekstblok is de keuze voor XML waarschijnlijk niet gerechtvaardigd.

Vanuit dit perspectief is er een eenvoudige manier om te controleren hoe goed een XML-schema is gemaakt. Neem bijvoorbeeld een document in het veronderstelde schema en verwijder alle tags en attributen. Als wat overblijft geen zin heeft (of als er een lege regel overblijft), dan is uw schema ofwel verkeerd opgebouwd, of had u eenvoudigweg geen XML moeten gebruiken.

Hieronder geef ik enkele van de meest voorkomende voorbeelden van verkeerd opgebouwde schema's.

Hier zien we een voorbeeld van een ongegronde en vreemde (ook al is het vrij gebruikelijk) poging om met XML een eenvoudige "sleutel-waarde" woordenlijst uit te drukken. Als we alle tags en attributen verwijderen, blijft er een lege regel over. In wezen vertegenwoordigt dit document, hoe absurd het ook klinkt, een semantische annotatie van een lege regel.

<root name="John" city="London" />

Wat nog erger is, is dat we hier niet alleen te maken hebben met een semantische annotatie van een lege regel als een extravagante manier om een woordenboek uit te drukken - deze keer is het 'woordenboek' rechtstreeks gecodeerd in de vorm van attributen van het wortelelement. Hierdoor wordt de gedefinieerde set attribuutnamen op het element onbepaald en dynamisch. Bovendien blijkt hieruit dat alles wat de auteur eigenlijk wilde uitdrukken, een eenvoudige 'sleutel-waarde' syntaxis was, maar in plaats daarvan heeft hij een volslagen vreemde beslissing genomen om XML toe te passen, waarbij hij de eenzame lege element eenvoudig als een voorvoegsel voor het gebruik van de syntaxis van attributen heeft afgedwongen. Dit soort schema's kom ik heel vaak tegen.

John
  London

Dit is al een verbetering, maar nu zijn de sleutels om de een of andere reden metadata, en de waarden niet. Een vrij vreemde kijk op woordenboeken. Als je alle tags en attributen verwijderd, gaat de helft van de informatie verloren.

De juiste weergave van een woordenboek in XML zou er ongeveer zo uitzien:

Name
    John
  
  
    City
    London

Maar als mensen de vreemde beslissing nemen om XML te gebruiken als dataformaat en vervolgens daarmee het woordenboek te ordenen, moeten ze begrijpen dat wat ze doen ongepast en onhandig is. Vaak maken ontwerpers ook de fout om XML te kiezen voor hun applicaties. Maar nog vaker verergeren ze de situatie met zinloos gebruik van XML in een van de bovengenoemde vormen, negerend het feit dat XML hiervoor gewoon niet geschikt is.

De slechtste XML-schema? Trouwens, de prijs voor de slechtste XML-schema die ik ooit heb gezien, gaat naar het bestandsformaat voor automatische resourceallocatie configuratiebestanden voor Polycom VoIP-telefoons. Dergelijke bestanden vereisen dat XML-bestanden via TFTP worden gedownload, die… In ieder geval, hier is een fragment van zo'n bestand:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

Dit is geen slechte grap van iemand. En dit is niet mijn verzinsel:

Elementen worden gewoon gebruikt als een prefix voor het koppelen van attributen, die zelf hiërarchische namen hebben.
Als je waarden aan meerdere instanties van een bepaalde soort record wilt toekennen, moet je attributenamen gebruiken, waarin indexen zijn..
Bovendien moeten attributen die beginnen met softkey.ook worden geplaatst op elementen <softkey/>, attributen die beginnen met feature.ook worden geplaatst op elementen <feature/> enzovoort, ondanks dat dit volkomen overbodig lijkt en op het eerste gezicht zinloos is.
En tot slot, als je hoopte dat het eerste onderdeel van de attribuutnaam altijd overeenkomt met de naam van het element - dat is niet het geval! Bij voorbeeld, attributen up. moeten worden gekoppeld aan <userpreferences/>. De volgorde waarin attributen aan elementen worden gekoppeld, is willekeurig en praktisch volledig.

Documenten of gegevens. Af en toe maakt iemand absoluut vreemde dingen door te proberen XML en JSON met elkaar te vergelijken, wat aantoont dat ze geen van beide begrijpen. XML is een opmaaktaal voor documenten. JSON daarentegen is een formaat voor gestructureerde gegevens, dus ze met elkaar vergelijken is net zoiets als proberen warm met zacht te vergelijken.

Om dit te begrijpen, helpt het om het concept van het verschil tussen documenten en gegevens. Voor XML kan men bij benadering een machine-leesbaar document nemen. Hoewel het bedoeld is voor machinelezen, verwijst het metaforisch naar documenten, en vanuit dat perspectief is het feitelijk vergelijkbaar met PDF-documenten, die meestal niet machineleesbaar zijn.

Bijvoorbeeld, in XML is de volgorde van elementen belangrijk. In JSON heeft de volgorde van key-value paren binnen objecten geen betekenis en is niet gedefinieerd. Als je een ongeordend woordenboek van key-value paren wilt verkrijgen, maakt de feitelijke volgorde waarin de elementen in dit bestand volgen, niet uit. Maar je kunt uit deze gegevens veel verschillende documentenvormen, omdat er een bepaalde volgorde in het document is. Metaforisch gezien is dit vergelijkbaar met een document op papier, hoewel het geen fysieke afmetingen heeft in tegenstelling tot een print of PDF-bestand.

In mijn voorbeeld van de juiste weergave van een woordenboek in XML wordt de volgorde van de elementen in het woordenboek getoond, in tegenstelling tot de weergave in JSON. Ik kan deze volgorde niet negeren: deze lineariteit is inherent aan het documentmodel en het XML-formaat. Iemand kan besluiten deze volgorde te negeren bij de interpretatie van dit XML-document, maar hier over discussiëren heeft weinig zin, aangezien deze kwestie buiten de discussie over het formaat zelf valt. Bovendien, als het document in een browser zichtbaar wordt gemaakt door een stylesheet eraan te bevestigen, kan worden gezien dat de woordenboek elementen in een bepaalde volgorde volgen, en geen andere.

Met andere woorden, een woordenboek (een fragment van gestructureerde gegevens) kan worden omgevormd tot n verschillende mogelijke documenten (in XML-formaat, PDF, op papier, enz.), waar n — het aantal mogelijke combinaties van elementen in het woordenboek, en daarbij hebben we nog niet rekening gehouden met andere mogelijke variabelen.

Daaruit volgt ook dat als je alleen gegevens wilt overdragen, het gebruik van een machineleesbaar document inefficiënt zal zijn. Het maakt gebruik van een model dat in dit geval overbodig is, dit zal alleen maar in de weg zitten. Bovendien is het nodig om een programma te schrijven om de originele gegevens te extraheren. Het heeft waarschijnlijk geen zin om XML te gebruiken voor iets dat op een bepaald moment niet in documentvorm wordt opgemaakt (zoals via CSS of XSLT, of beide), aangezien dit de belangrijkste (ook al niet enige) reden is om aan het documentmodel vast te houden.

Bovendien, omdat er in XML geen concept van getallen (of booleaanse uitdrukkingen of andere datatypes) is, worden alle getallen die in dit formaat worden gepresenteerd slechts als aanvullende tekst beschouwd. Voor het extraheren van gegevens moet het schema en de relatie ervan met de bijbehorende weergegeven gegevens bekend zijn. Ook moet men weten wanneer een bepaald element van de tekst uit de context een getal vertegenwoordigt, en het als zodanig moet worden omgezet, enz.

Het proces van het extraheren van gegevens uit XML-documenten verschilt niet veel van het proces van het herkennen van gescande documenten die bijvoorbeeld tabellen bevatten met meerdere pagina's met cijfers. Ja, dit is in principe mogelijk, maar het is niet de meest optimale weg — tenzij in extreme gevallen waarin er helemaal geen andere opties zijn. Een verstandige oplossing zou zijn om gewoon een digitale kopie van de originele gegevens te vinden, niet vastgelegd in het documentmodel, waarin de gegevens zijn samengevoegd met hun specifieke tekstuele weergave.

Het verbaast me dan ook niet dat XML populair is in het bedrijfsleven. De reden hiervoor is juist dat het documentformaat (op papier) begrijpelijk en vertrouwd is voor bedrijven, en zij willen blijven werken met een bekend en begrijpelijk model. Om dezelfde reden worden PDF-documenten in het bedrijfsleven te vaak gebruikt in plaats van meer machineverwerkbare formaten — omdat ze nog steeds gebonden zijn aan het idee van een afdrukpagina met een bepaald fysiek formaat. Dit geldt zelfs voor documenten die waarschijnlijk nooit geprint zullen worden (bijvoorbeeld een PDF-bestand van 8000 pagina's met registratiedocumentatie). Vanuit dit perspectief is het gebruik van XML in het bedrijfsleven in wezen een uiting van skeuomorfisme. Mensen begrijpen het metaforische idee van een afdrukpagina van beperkte grootte, en zij begrijpen hoe zij bedrijfsprocessen kunnen opzetten op basis van papieren documenten. Als dat uw leidraad is, vertegenwoordigen documenten zonder een beperkt fysiek formaat, die machineleesbaar zijn — XML-documenten — een innovatie, terwijl ze tegelijkertijd een bekend en comfortabel alternatief voor documenten zijn. Wat niet wegneemt dat ze een onjuiste en te skeuomorfe manier van gegevensrepresentatie blijven.

Tot op heden zijn de enige XML-schema's die ik echt een correct gebruik van dit formaat kan noemen XHTML en DocBook.

Bron: habr.com

XML wordt vrijwel altijd verkeerd gebruikt