XML-sproget blev opfundet i 1996. Så snart den dukkede op, var mulighederne for dens anvendelse allerede begyndt at blive misforstået, og til de formål, som de forsøgte at tilpasse den til, var det ikke det bedste valg.
Det er ingen overdrivelse at sige, at langt de fleste XML-skemaer, jeg har set, var upassende eller forkert brug af XML. Desuden viste denne brug af XML en grundlæggende misforståelse af, hvad XML handlede om.
XML er et opmærkningssprog. Dette er ikke et dataformat. De fleste XML-skemaer har eksplicit overset denne skelnen og forveksler XML med et dataformat, hvilket i sidste ende resulterer i en fejl ved valg af XML, fordi det er dataformatet, der faktisk er brug for.
Uden at gå for meget i detaljer er XML bedst egnet til at annotere tekstblokke med struktur og metadata. Hvis dit hovedmål ikke er at arbejde med en tekstblok, er det usandsynligt, at valget af XML er berettiget.
Fra dette synspunkt er der en enkel måde at kontrollere, hvor godt XML-skemaet er lavet. Lad os som eksempel tage et dokument i det tilsigtede skema og fjerne alle tags og attributter fra det. Hvis det, der er tilbage, ikke giver mening (eller hvis der er en tom linje tilbage), så er dit skema enten ikke bygget korrekt, eller også burde du simpelthen ikke have brugt XML.
Nedenfor vil jeg give nogle af de mest almindelige eksempler på forkert konstruerede kredsløb.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Her ser vi et eksempel på et ubegrundet og mærkeligt (dog meget almindeligt) forsøg på at udtrykke en simpel nøgleværdiordbog i XML. Hvis du fjerner alle tags og attributter, står du tilbage med en tom række. I bund og grund er dette dokument, uanset hvor absurd det måtte lyde, en semantisk anmærkning af en tom linje.
<root name="John" city="London" />For at gøre ondt værre har vi her ikke bare en semantisk annotation af en tom streng som en ekstravagant måde at udtrykke en ordbog på – denne gang er "ordbogen" direkte kodet som attributter til rodelementet. Dette gør det givne sæt af attributnavne på et element udefineret og dynamisk. Desuden viser det, at alt, hvad forfatteren virkelig ønskede at udtrykke, var en simpel nøgleværdi-syntaks, men i stedet tog han den helt bizarre beslutning om at anvende XML, og tvang brugen af et enkelt tomt element blot som et præfiks til at bruge attributsyntaks. Og jeg støder meget ofte på sådanne ordninger.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Dette er noget bedre, men nu er nøglerne af en eller anden grund metadata, og værdierne er det ikke. Et meget mærkeligt blik på ordbøger. Hvis du fjerner alle tags og attributter, vil halvdelen af informationen gå tabt.
Et korrekt ordbogsudtryk i XML ville se sådan ud:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Men hvis folk har taget den mærkelige beslutning at bruge XML som dataformat og derefter bruge det til at organisere et ordforråd, så burde de forstå, at det, de gør, er upassende og ikke praktisk. Det er også almindeligt, at designere ved en fejl vælger XML til at skabe deres applikationer. Men endnu oftere gør de tingene værre ved meningsløst at bruge XML i en af de ovenfor beskrevne former, idet de ignorerer det faktum, at XML simpelthen ikke er egnet til dette.
Værste XML-skema? Præmien pr det værste XML-skema jeg nogensinde har set, Henter det automatiske klargøringskonfigurationsfilformat til Polycom IP-telefonitelefoner. Sådanne filer kræver download af XML-anmodningsfiler via TFTP, som... Generelt er her et uddrag fra 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="..." />Dette er ikke nogens dårlige joke. Og dette er ikke min opfindelse:
- elementer bruges simpelthen som et præfiks til at vedhæfte attributter, som selv har hierarkiske navne.
- Hvis du vil tildele værdier til flere forekomster af en bestemt type post, skal du bruge attributnavne til at gøre dette. som har indekser.
- Hertil kommer attributter, der starter med
softkey., skal placeres på elementer<softkey/>, attributter, der starter medfeature., skal placeres på elementer<feature/>osv., på trods af at det ser helt unødvendigt og ved første øjekast meningsløst ud. - Og endelig, hvis du håbede, at den første komponent af et attributnavn altid ville være det samme som elementnavnet - intet lignende! For eksempel attributter
up.skal knyttes til<userpreferences/>. Rækkefølgen for at knytte attributnavne til elementer er vilkårlig, næsten fuldstændig.
Dokumenter eller data. En gang imellem gør nogen noget helt underligt ved at prøve at sammenligne XML og JSON — og dermed vise, at de heller ikke forstår. XML er et dokumentopmærkningssprog. JSON er et struktureret dataformat, så at sammenligne dem med hinanden er som at prøve at sammenligne varme med bløde.
Begrebet forskellen mellem dokumenter og data. Som en analog til XML kan vi betinget tage et maskinlæsbart dokument. Selvom det er beregnet til at være maskinlæsbart, refererer det metaforisk til dokumenter, og ud fra dette synspunkt er det faktisk sammenligneligt med PDF-dokumenter, som oftest ikke er maskinlæsbare.
For eksempel i XML er rækkefølgen af elementer afgørende. Men i JSON er rækkefølgen af nøgle-værdi-par i objekter meningsløs og udefineret. Hvis du vil have en uordnet ordbog over nøgleværdi-par, er den faktiske rækkefølge, som elementerne vises i i den pågældende fil, ligegyldig. Men du kan danne mange forskellige typer data ud fra disse data. dokumenter, fordi der er en bestemt rækkefølge i dokumentet. Metaforisk er det analogt med et dokument på papir, selvom det ikke har fysiske dimensioner, i modsætning til en udskrift eller PDF-fil.
Mit eksempel på en ordentlig XML-ordbogsrepræsentation viser rækkefølgen af elementerne i ordbogen, i modsætning til JSON-repræsentationen. Jeg kan ikke ignorere denne rækkefølge: denne linearitet er iboende i dokumentmodellen og XML-formatet. Nogle kan vælge at ignorere rækkefølgen, når de fortolker dette XML-dokument, men det nytter ikke at skændes om dette, da spørgsmålet ligger uden for rammerne af en diskussion af selve formatet. Desuden, hvis du gør dokumentet synligt i browseren ved at vedhæfte et cascading stylesheet til det, vil du se, at ordbogselementerne vises i en bestemt rækkefølge og ikke i nogen anden.
Med andre ord kan en ordbog (et stykke struktureret data) konverteres til n forskellige mulige dokumenter (i XML, PDF, papir osv.), hvor n - antallet af mulige kombinationer af elementer i ordbogen, og vi har endnu ikke taget højde for andre mulige variable.
Det følger dog også, at hvis du kun ønsker at overføre data, så vil det ikke være effektivt at bruge et maskinlæsbart dokument til dette. Den bruger en model, som i dette tilfælde er overflødig, den kommer kun i vejen. Derudover skal du skrive et program for at udtrække kildedataene. Der er næppe nogen mening i at bruge XML til noget, der ikke vil blive formateret som et dokument på et tidspunkt (f.eks. ved at bruge CSS eller XSLT eller begge dele), da det er den vigtigste (hvis ikke den eneste) grund til at gøre det. til dokumentmodellen.
Da XML desuden ikke har noget begreb om tal (eller booleske udtryk eller andre datatyper), betragtes alle tal repræsenteret i dette format som blot ekstra tekst. For at udtrække data skal skemaet og dets forhold til de tilsvarende data, der udtrykkes, være kendt. Du skal også vide, hvornår et bestemt tekstelement ud fra konteksten repræsenterer et tal og skal konverteres til et tal osv.
Processen med at udtrække data fra XML-dokumenter er således ikke så forskellig fra processen med at genkende scannede dokumenter, der for eksempel indeholder tabeller, der udgør mange sider med numeriske data. Ja, det er muligt at gøre dette i princippet, men det er ikke den mest optimale måde, undtagen som en sidste udvej, hvor der absolut ikke er andre muligheder. En rimelig løsning er blot at finde en digital kopi af de originale data, der ikke er indlejret i en dokumentmodel, der kombinerer dataene med dens specifikke tekstgengivelse.
Når det er sagt, så overrasker det mig overhovedet ikke, at XML er populært i erhvervslivet. Grunden til dette er netop, at dokumentformatet (på papiret) er forståeligt og velkendt for erhvervslivet, og de ønsker fortsat at bruge en velkendt og forståelig model. Af samme grund bruger virksomheder alt for ofte PDF-dokumenter i stedet for mere maskinlæsbare formater – fordi de stadig er bundet til konceptet om en udskrevet side med en bestemt fysisk størrelse. Dette gælder endda for dokumenter, der næppe nogensinde vil blive udskrevet (f.eks. en 8000-siders PDF med registreringsdokumentation). Fra dette synspunkt er brugen af XML i erhvervslivet i det væsentlige en manifestation af skeuomorfisme. Folk forstår den metaforiske idé om en trykt side af begrænset størrelse, og de forstår, hvordan man skaber forretningsprocesser baseret på trykte dokumenter. Hvis det er din guide, repræsenterer dokumenter uden fysiske størrelsesbegrænsninger, der er maskinlæsbare - XML-dokumenter - innovation, samtidig med at de er en velkendt og behagelig dokumentmodpart. Dette forhindrer dem ikke i at forblive en forkert og alt for skeuomorf måde at præsentere data på.
Til dato er de eneste XML-skemaer, jeg kender til, som jeg virkelig kan kalde en gyldig brug af formatet, XHTML og DocBook.
Kilde: www.habr.com