XML wordt bijna altijd misbruikt

De XML-taal werd uitgevonden in 1996. Zodra het was verschenen, begonnen de mogelijkheden van de toepassing ervan al verkeerd te worden begrepen, en voor de doeleinden waarvoor ze het probeerden aan te passen, was het niet de beste keuze.

Het is niet overdreven om te zeggen dat de overgrote meerderheid van de XML-schema's die ik heb gezien ongepast of onjuist gebruik van XML is. Bovendien bracht dit gebruik van XML een fundamenteel misverstand aan het licht over waar XML over ging.

XML is een opmaaktaal. Dit is geen gegevensformaat. De meeste XML-schema's hebben dit onderscheid expliciet over het hoofd gezien, waardoor XML wordt verward met een gegevensformaat, wat uiteindelijk resulteert in een fout bij het kiezen van XML omdat dit het gegevensformaat is dat feitelijk nodig is.

Zonder al te veel in detail te treden: XML is het meest geschikt voor het annoteren van tekstblokken met structuur en metadata. Als het niet uw hoofddoel is om met een tekstblok te werken, is de keuze voor XML waarschijnlijk niet gerechtvaardigd.

Vanuit dit oogpunt is er een eenvoudige manier om te controleren hoe goed het XML-schema is gemaakt. Laten we als voorbeeld een document in het beoogde schema nemen en alle tags en attributen eruit verwijderen. Als wat er overblijft geen zin heeft (of als er een lege regel over is), dan is uw schema niet correct opgebouwd of had u simpelweg geen XML moeten gebruiken.

Hieronder geef ik enkele van de meest voorkomende voorbeelden van verkeerd geconstrueerde circuits.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Hier zien we een voorbeeld van een ongegronde en vreemde (hoewel zeer gebruikelijke) poging om een ​​eenvoudig sleutel-waardewoordenboek in XML uit te drukken. Als u alle tags en attributen verwijdert, blijft er een lege rij over. In wezen is dit document, hoe absurd het ook mag klinken, een semantische annotatie van een lege regel.

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

Tot overmaat van ramp hebben we hier niet alleen een semantische annotatie van een lege string als een extravagante manier om een ​​woordenboek uit te drukken - deze keer wordt het "woordenboek" rechtstreeks gecodeerd als attributen van het hoofdelement. Dit maakt de gegeven set attribuutnamen op een element ongedefinieerd en dynamisch. Bovendien laat het zien dat het enige dat de auteur echt wilde uitdrukken een eenvoudige sleutel-waarde-syntaxis was, maar dat hij in plaats daarvan de absoluut bizarre beslissing nam om XML toe te passen, waarbij hij het gebruik van een enkel leeg element eenvoudigweg als voorvoegsel dwong om de attribuutsyntaxis te gebruiken. En ik kom dergelijke schema's heel vaak tegen.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Dit is iets beters, maar om de een of andere reden zijn de sleutels metadata en de waarden niet. Een heel vreemde kijk op woordenboeken. Als u alle tags en attributen verwijdert, gaat de helft van de informatie verloren.

Een correcte woordenboekuitdrukking in XML zou er ongeveer zo uitzien:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Maar als mensen de vreemde beslissing hebben genomen om XML als gegevensformaat te gebruiken en het vervolgens te gebruiken om een ​​vocabulaire te organiseren, dan zouden ze moeten begrijpen dat wat ze doen ongepast en niet handig is. Het komt ook vaak voor dat ontwerpers per ongeluk XML kiezen om hun applicaties te maken. Maar nog vaker maken ze de zaken nog erger door XML zinloos te gebruiken in een van de hierboven beschreven vormen, waarbij ze voorbijgaan aan het feit dat XML daarvoor simpelweg niet geschikt is.

Slechtste XML-schema? Trouwens, de prijs voor het slechtste XML-schema dat ik ooit heb gezien, Haalt het configuratiebestandsformaat voor automatische inrichting op voor Polycom IP-telefonietelefoons. Dergelijke bestanden vereisen het downloaden van XML-aanvraagbestanden via TFTP, wat... Over het algemeen is hier een fragment uit 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 niet iemands slechte grap. En dit is niet mijn uitvinding:

• elementen worden eenvoudigweg gebruikt als voorvoegsel om attributen toe te voegen, die zelf hiërarchische namen hebben.
• Als u waarden wilt toewijzen aan meerdere exemplaren van een bepaald type record, moet u hiervoor attribuutnamen gebruiken. die indexen hebben.
• Bovendien zijn attributen die beginnen met softkey., moet op elementen worden geplaatst <softkey/>, attributen beginnend met feature., moet op elementen worden geplaatst <feature/> enz., ondanks het feit dat het volkomen onnodig en op het eerste gezicht zinloos lijkt.
• En tot slot, als je hoopte dat het eerste onderdeel van een attribuutnaam altijd hetzelfde zou zijn als de elementnaam: zoiets is er niet! Attributen bijvoorbeeld up. aan moet worden gehecht <userpreferences/>. De volgorde waarin attribuutnamen aan elementen worden gekoppeld, is vrijwel volledig willekeurig.

Documenten of gegevens. Af en toe doet iemand iets heel raars door XML en JSON te vergelijken, en daarmee te laten zien dat hij het ook niet begrijpt. XML is een opmaaktaal voor documenten. JSON is een gestructureerd gegevensformaat, dus het vergelijken ervan met elkaar is alsof je warm met zacht probeert te vergelijken.

Het concept van het verschil tussen documenten en gegevens. Als analoog van XML kunnen we voorwaardelijk een machinaal leesbaar document nemen. Hoewel het bedoeld is om machinaal leesbaar te zijn, verwijst het metaforisch naar documenten, en vanuit dit oogpunt is het eigenlijk vergelijkbaar met PDF-documenten, die meestal niet machinaal leesbaar zijn.

In XML is de volgorde van de elementen bijvoorbeeld van belang. Maar in JSON is de volgorde van sleutel-waardeparen binnen objecten betekenisloos en ongedefinieerd. Als je een ongeordend woordenboek van sleutel-waardeparen wilt krijgen, doet de feitelijke volgorde waarin de elementen in dat bestand verschijnen er niet toe. Maar u kunt uit deze gegevens veel verschillende soorten gegevens vormen. documenten, omdat er een bepaalde volgorde in het document zit. Metaforisch gezien is het analoog aan een document op papier, hoewel het geen fysieke afmetingen heeft, in tegenstelling tot een afdruk of PDF-bestand.

Mijn voorbeeld van een goede XML-woordenboekrepresentatie toont de volgorde van de elementen in het woordenboek, in tegenstelling tot de JSON-representatie. Ik kan deze volgorde niet negeren: deze lineariteit is inherent aan het documentmodel en het XML-formaat. Sommigen kiezen er misschien voor om de volgorde te negeren bij het interpreteren van dit XML-document, maar het heeft geen zin om hierover te discussiëren, aangezien de kwestie buiten het bestek van een bespreking van het formaat zelf valt. Als u het document bovendien zichtbaar maakt in de browser door er een cascading stylesheet aan toe te voegen, zult u zien dat de woordenboekelementen in een bepaalde volgorde verschijnen en niet in een andere.

Met andere woorden, een woordenboek (een stukje gestructureerde gegevens) kan worden omgezet in n verschillende mogelijke documenten (in XML, PDF, papier, etc.), waar n - het aantal mogelijke combinaties van elementen in het woordenboek, en we hebben nog geen rekening gehouden met andere mogelijke variabelen.

Hieruit volgt echter ook dat als u alleen gegevens wilt overbrengen, het gebruik van een machineleesbaar document hiervoor niet effectief zal zijn. Er wordt gebruik gemaakt van een model, wat in dit geval overbodig is; het staat alleen maar in de weg. Om de brongegevens te extraheren, moet u bovendien een programma schrijven. Het heeft nauwelijks zin om XML te gebruiken voor iets dat op een gegeven moment niet als document zal worden opgemaakt (bijvoorbeeld met behulp van CSS of XSLT, of beide), aangezien dat de belangrijkste (zo niet de enige) reden is om dit te doen. naar het documentmodel.

Omdat XML bovendien geen concept van getallen (of Booleaanse expressies of andere gegevenstypen) heeft, worden alle getallen die in dit formaat worden weergegeven, beschouwd als slechts aanvullende tekst. Om gegevens te extraheren, moet het schema en de relatie ervan met de overeenkomstige gegevens die worden uitgedrukt, bekend zijn. U moet ook weten wanneer, op basis van de context, een bepaald tekstelement een getal vertegenwoordigt en naar een getal moet worden geconverteerd, enz.

Het proces van het extraheren van gegevens uit XML-documenten verschilt dus niet zoveel van het proces van het herkennen van gescande documenten die bijvoorbeeld tabellen bevatten die vele pagina's met numerieke gegevens vormen. Ja, het is in principe mogelijk om dit te doen, maar dit is niet de meest optimale manier, behalve als laatste redmiddel, als er absoluut geen andere opties zijn. Een redelijke oplossing is om eenvoudigweg een digitale kopie van de originele gegevens te vinden die niet is ingebed in een documentmodel dat de gegevens combineert met de specifieke tekstuele representatie ervan.

Dat gezegd hebbende verbaast het mij helemaal niet dat XML populair is in het bedrijfsleven. De reden hiervoor is juist dat het documentformaat (op papier) begrijpelijk en vertrouwd is voor het bedrijfsleven, en zij een bekend en begrijpelijk model willen blijven hanteren. Om dezelfde reden gebruiken bedrijven te vaak PDF-documenten in plaats van meer machineleesbare formaten - omdat ze nog steeds gebonden zijn aan het concept van een afgedrukte pagina met een specifiek fysiek formaat. Dit geldt zelfs voor documenten waarvan het onwaarschijnlijk is dat ze ooit zullen worden afgedrukt (bijvoorbeeld een pdf van 8000 pagina's met registerdocumentatie). Vanuit dit gezichtspunt is het gebruik van XML in het bedrijfsleven in wezen een uiting van skeuomorfisme. Mensen begrijpen het metaforische idee van een afgedrukte pagina van beperkte omvang, en ze begrijpen hoe ze bedrijfsprocessen kunnen creëren op basis van gedrukte documenten. Als dat uw leidraad is, vertegenwoordigen documenten zonder fysieke afmetingen die machinaal leesbaar zijn (XML-documenten) innovatie, terwijl ze een vertrouwde en comfortabele document-tegenhanger zijn. Dit belet niet dat ze een onjuiste en al te skeuomorfe manier blijven om gegevens te presenteren.

Tot nu toe zijn de enige XML-schema's die ik ken en die ik echt een geldig gebruik van het formaat kan noemen, XHTML en DocBook.

Bron: www.habr.com