XML missbrukas nästan alltid

XML-språket uppfanns 1996. Inte så fort hade det dykt upp förrän möjligheterna med dess tillämpning redan hade börjat missförstås, och för de syften som de försökte anpassa det till var det inte det bästa valet.

Det är ingen överdrift att säga att de allra flesta XML-scheman jag har sett var olämpliga eller felaktiga användningar av XML. Dessutom visade denna användning av XML ett grundläggande missförstånd av vad XML handlade om.

XML är ett märkningsspråk. Detta är inte ett dataformat. De flesta XML-scheman har uttryckligen förbisett denna distinktion och blandar ihop XML med ett dataformat, vilket i slutändan resulterar i ett misstag när man väljer XML eftersom det är dataformatet som faktiskt behövs.

Utan att gå in på för mycket detaljer är XML bäst lämpat för att kommentera textblock med struktur och metadata. Om ditt huvudmål inte är att arbeta med ett textblock är det osannolikt att valet av XML är motiverat.

Ur denna synvinkel finns det ett enkelt sätt att kontrollera hur väl XML-schemat är gjort. Låt oss som exempel ta ett dokument i det avsedda schemat och ta bort alla taggar och attribut från det. Om det som är kvar inte är meningsfullt (eller om det finns en tom rad kvar), så är antingen ditt schema inte byggt korrekt eller så borde du helt enkelt inte ha använt XML.

Nedan kommer jag att ge några av de vanligaste exemplen på felaktigt konstruerade kretsar.

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

Här ser vi ett exempel på ett ogrundat och märkligt (men mycket vanligt) försök att uttrycka en enkel nyckel-värde-lexikon i XML. Om du tar bort alla taggar och attribut kommer du att lämnas med en tom rad. I huvudsak är detta dokument, hur absurt det än låter, en semantisk anteckning av en tom rad.

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

För att göra saken värre har vi inte bara en semantisk anteckning av en tom sträng här som ett extravagant sätt att uttrycka en ordbok – den här gången är "ordboken" direkt kodad som attribut för rotelementet. Detta gör den givna uppsättningen av attributnamn på ett element odefinierad och dynamisk. Dessutom visar det att allt författaren verkligen ville uttrycka var en enkel nyckel-värde-syntax, men i stället tog han det absolut bisarra beslutet att tillämpa XML, och tvingade användningen av ett enda tomt element helt enkelt som ett prefix för att använda attributsyntax. Och jag stöter på sådana upplägg väldigt ofta.

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

Det här är något bättre, men nu är nycklarna av någon anledning metadata och värdena är det inte. En mycket märklig titt på ordböcker. Om du tar bort alla taggar och attribut kommer hälften av informationen att gå förlorad.

Ett korrekt ordboksuttryck i XML skulle se ut ungefär så här:

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

Men om människor har tagit det konstiga beslutet att använda XML som dataformat och sedan använda det för att organisera ett ordförråd, då borde de förstå att det de gör är olämpligt och inte bekvämt. Det är också vanligt att designers av misstag väljer XML för att skapa sina applikationer. Men ännu oftare gör de saken värre genom att meningslöst använda XML i någon av de former som beskrivs ovan, utan att ignorera att XML helt enkelt inte är lämplig för detta.

Sämsta XML-schemat? Förresten, priset för det sämsta XML-schemat jag någonsin sett, Hämtar filformatet för automatisk provisioneringskonfiguration för Polycom IP-telefonitelefoner. Sådana filer kräver nedladdning av XML-förfrågningsfiler via TFTP, vilket... I allmänhet är här ett utdrag från en sådan fil:

<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="..." />

Det här är inte någons dåliga skämt. Och det här är inte min uppfinning:

• element används helt enkelt som ett prefix för att bifoga attribut, som själva har hierarkiska namn.
• Om du vill tilldela värden till flera instanser av en viss typ av post måste du använda attributnamn för att göra detta. som har index.
• Dessutom attribut som börjar med softkey., måste placeras på element <softkey/>, attribut som börjar med feature., måste placeras på element <feature/> osv, trots att det ser helt onödigt och vid första anblicken meningslöst ut.
• Och slutligen, om du hoppades att den första komponenten i ett attributnamn alltid skulle vara samma som elementnamnet - inget liknande! Till exempel attribut up. måste fästas vid <userpreferences/>. Ordningen för att koppla attributnamn till element är godtycklig, nästan helt.

Dokument eller data. Då och då gör någon något helt konstigt genom att försöka jämföra XML och JSON — och därmed visa att de inte heller förstår. XML är ett dokumentuppmärkningsspråk. JSON är ett strukturerat dataformat, så att jämföra dem med varandra är som att försöka jämföra varma med mjuka.

Begreppet skillnaden mellan dokument och data. Som en analog till XML kan vi villkorligt ta ett maskinläsbart dokument. Även om det är tänkt att vara maskinläsbart, hänvisar det metaforiskt till dokument, och är ur denna synvinkel faktiskt jämförbart med PDF-dokument, som oftast inte är maskinläsbara.

Till exempel, i XML spelar ordningen på element roll. Men i JSON är ordningen för nyckel-värdepar inom objekt meningslös och odefinierad. Om du vill få en oordnad ordlista med nyckel-värdepar spelar ingen roll i vilken ordning elementen visas i den filen. Men du kan bilda många olika typer av data från denna data. av dokument, eftersom det finns en viss ordning i dokumentet. Metaforiskt är det analogt med ett dokument på papper, även om det inte har fysiska dimensioner, till skillnad från en utskrift eller PDF-fil.

Mitt exempel på en riktig XML-ordboksrepresentation visar ordningen på elementen i ordboken, i motsats till JSON-representationen. Jag kan inte ignorera denna ordning: denna linjäritet är inneboende i dokumentmodellen och XML-formatet. Vissa kanske väljer att ignorera ordningen när de tolkar detta XML-dokument, men det är ingen idé att bråka om detta eftersom frågan ligger utanför ramen för en diskussion om själva formatet. Dessutom, om du gör dokumentet synligt i webbläsaren genom att bifoga en överlappande stilmall till det, kommer du att se att ordbokselementen visas i en viss ordning och inte i någon annan.

Med andra ord kan en ordbok (ett stycke strukturerad data) konverteras till n olika möjliga dokument (i XML, PDF, papper, etc.), där n - antalet möjliga kombinationer av element i ordboken, och vi har ännu inte tagit hänsyn till andra möjliga variabler.

Men det följer också att om du bara vill överföra data, kommer det inte att vara effektivt att använda ett maskinläsbart dokument för detta. Den använder en modell, som i det här fallet är överflödig, den kommer bara att vara i vägen. Dessutom, för att extrahera källdata, måste du skriva ett program. Det finns knappast någon mening med att använda XML för något som inte kommer att formateras som ett dokument någon gång (säg att använda CSS eller XSLT, eller båda), eftersom det är den främsta (om inte den enda) anledningen till att göra det. till dokumentmodellen.

Dessutom, eftersom XML inte har något begrepp för siffror (eller booleska uttryck eller andra datatyper), betraktas alla siffror som representeras i detta format bara som extra text. För att extrahera data måste schemat och dess förhållande till motsvarande data som uttrycks vara känt. Du behöver också veta när, baserat på sammanhanget, ett visst textelement representerar ett tal och bör konverteras till ett tal osv.

Processen att extrahera data från XML-dokument skiljer sig således inte så mycket från processen att känna igen skannade dokument som innehåller till exempel tabeller som bildar många sidor med numerisk data. Ja, det är möjligt att göra detta i princip, men detta är inte det mest optimala sättet, förutom som en sista utväg, när det absolut inte finns några andra alternativ. En rimlig lösning är att helt enkelt hitta en digital kopia av originaldata som inte är inbäddad i en dokumentmodell som kombinerar data med dess specifika textrepresentation.

Som sagt, det förvånar mig inte alls att XML är populärt i näringslivet. Anledningen till detta är just att dokumentformatet (på papper) är begripligt och bekant för näringslivet, och de vill fortsätta använda en bekant och begriplig modell. Av samma anledning använder företag alltför ofta PDF-dokument istället för mer maskinläsbara format – eftersom de fortfarande är bundna till konceptet med en utskriven sida med en viss fysisk storlek. Detta gäller till och med dokument som sannolikt inte kommer att skrivas ut (till exempel en 8000 XNUMX-sidig PDF-fil med registerdokumentation). Ur denna synvinkel är användningen av XML i affärer i huvudsak en manifestation av skeuomorfism. Människor förstår den metaforiska idén med en tryckt sida av begränsad storlek, och de förstår hur man skapar affärsprocesser baserade på tryckta dokument. Om det är din guide, dokument utan fysiska storleksbegränsningar som är maskinläsbara – XML-dokument – ​​representerar innovation samtidigt som de är en välbekant och bekväm dokumentmotsvarighet. Detta hindrar inte dem från att förbli ett felaktigt och alltför skeuomorft sätt att presentera data.

Hittills är de enda XML-scheman jag känner till som jag verkligen kan kalla en giltig användning av formatet XHTML och DocBook.

Källa: will.com