XML-språket ble oppfunnet i 1996. Ikke før hadde den dukket opp før mulighetene for anvendelsen allerede hadde begynt å bli misforstått, og for de formålene de prøvde å tilpasse den til, var det ikke det beste valget.
Det er ingen overdrivelse å si at de aller fleste XML-skjemaer jeg har sett var upassende eller feilaktig bruk av XML. Dessuten demonstrerte denne bruken av XML en grunnleggende misforståelse av hva XML dreide seg om.
XML er et merkespråk. Dette er ikke et dataformat. De fleste XML-skjemaer har eksplisitt oversett denne forskjellen, og forvekslet XML med et dataformat, noe som til slutt resulterer i en feil ved valg av XML fordi det er dataformatet som faktisk trengs.
Uten å gå for mye i detalj er XML best egnet for å kommentere tekstblokker med struktur og metadata. Hvis hovedmålet ditt ikke er å jobbe med en tekstblokk, er det neppe berettiget å velge XML.
Fra dette synspunktet er det en enkel måte å sjekke hvor godt XML-skjemaet er laget. La oss ta som eksempel et dokument i det tiltenkte skjemaet og fjerne alle tagger og attributter fra det. Hvis det som er igjen ikke gir mening (eller hvis det er en tom linje igjen), så er enten skjemaet ditt ikke bygget riktig, eller du burde rett og slett ikke ha brukt XML.
Nedenfor vil jeg gi noen av de vanligste eksemplene på feil konstruerte kretser.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Her ser vi et eksempel på et ubegrunnet og merkelig (men svært vanlig) forsøk på å uttrykke en enkel nøkkelverdi-ordbok i XML. Hvis du fjerner alle tagger og attributter, vil du stå igjen med en tom rad. I hovedsak er dette dokumentet, uansett hvor absurd det høres ut, en semantisk merknad av en tom linje.
<root name="John" city="London" />For å gjøre vondt verre har vi ikke bare en semantisk merknad av en tom streng her som en ekstravagant måte å uttrykke en ordbok på – denne gangen er «ordboken» direkte kodet som attributter til rotelementet. Dette gjør det gitte settet med attributtnavn på et element udefinert og dynamisk. Dessuten viser det at alt forfatteren egentlig ønsket å uttrykke var en enkel nøkkelverdi-syntaks, men i stedet tok han den helt bisarre beslutningen om å bruke XML, og tvang bruken av et enkelt tomt element bare som et prefiks for å bruke attributtsyntaks. Og jeg kommer over slike opplegg veldig ofte.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Dette er noe bedre, men nå er nøklene av en eller annen grunn metadata og verdiene er det ikke. Et veldig merkelig blikk på ordbøker. Hvis du fjerner alle tagger og attributter, vil halvparten av informasjonen gå tapt.
Et korrekt ordbokuttrykk i XML vil se omtrent slik ut:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Men hvis folk har tatt den merkelige beslutningen om å bruke XML som et dataformat og deretter bruke det til å organisere et vokabular, så burde de forstå at det de gjør er upassende og ikke praktisk. Det er også vanlig at designere feilaktig velger XML for å lage applikasjonene sine. Men enda oftere gjør de saken verre ved meningsløst å bruke XML i en av formene beskrevet ovenfor, og ignorerer det faktum at XML rett og slett ikke er egnet for dette.
Verste XML-skjema? For øvrig premien for det verste XML-skjemaet jeg noen gang har sett, Henter det automatiske klargjøringskonfigurasjonsfilformatet for Polycom IP-telefonitelefoner. Slike filer krever nedlasting av XML-forespørselsfiler via TFTP, som... Generelt er her et utdrag fra en slik 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 noens dårlige spøk. Og dette er ikke min oppfinnelse:
- elementer brukes ganske enkelt som et prefiks for å knytte attributter, som i seg selv har hierarkiske navn.
- Hvis du vil tilordne verdier til flere forekomster av en bestemt type post, må du bruke attributtnavn for å gjøre dette. som har indekser.
- I tillegg attributter som starter med
softkey., må plasseres på elementer<softkey/>, attributter som begynner medfeature., må plasseres på elementer<feature/>osv., til tross for at det ser helt unødvendig og ved første øyekast meningsløst ut. - Og til slutt, hvis du håpet at den første komponenten i et attributtnavn alltid ville være det samme som elementnavnet - ingenting sånt! For eksempel attributter
up.må festes til<userpreferences/>. Rekkefølgen for å knytte attributtnavn til elementer er vilkårlig, nesten fullstendig.
Dokumenter eller data. En gang i blant gjør noen noe helt rart ved å prøve å sammenligne XML og JSON – og dermed vise at de heller ikke forstår. XML er et dokumentmarkeringsspråk. JSON er et strukturert dataformat, så å sammenligne dem med hverandre er som å prøve å sammenligne varme med myke.
Konseptet med forskjellen mellom dokumenter og data. Som en analog av XML kan vi betinget ta et maskinlesbart dokument. Selv om det er ment å være maskinlesbart, refererer det metaforisk til dokumenter, og er fra dette synspunkt faktisk sammenlignbart med PDF-dokumenter, som oftest ikke er maskinlesbare.
For eksempel, i XML er rekkefølgen på elementene viktig. Men i JSON er rekkefølgen av nøkkel-verdi-par i objekter meningsløs og udefinert. Hvis du ønsker å få en uordnet ordbok med nøkkelverdi-par, spiller ingen rolle den faktiske rekkefølgen elementene vises i i den filen. Men du kan danne mange forskjellige typer data fra disse dataene. av dokumenter, fordi det er en viss rekkefølge i dokumentet. Metaforisk er det analogt med et dokument på papir, selv om det ikke har fysiske dimensjoner, i motsetning til en utskrift eller PDF-fil.
Mitt eksempel på en skikkelig XML-ordbokrepresentasjon viser rekkefølgen på elementene i ordboken, i motsetning til JSON-representasjonen. Jeg kan ikke ignorere denne rekkefølgen: denne lineariteten er iboende i dokumentmodellen og XML-formatet. Noen kan velge å ignorere rekkefølgen når de tolker dette XML-dokumentet, men det er ingen vits i å krangle om dette siden problemet ligger utenfor rammen av en diskusjon om selve formatet. Dessuten, hvis du gjør dokumentet synlig i nettleseren ved å legge ved et overlappende stilark til det, vil du se at ordbokelementene vises i en bestemt rekkefølge og ikke i noen annen.
Med andre ord kan en ordbok (et stykke strukturert data) konverteres til n ulike mulige dokumenter (i XML, PDF, papir, etc.), hvor n - antall mulige kombinasjoner av elementer i ordboken, og vi har ennå ikke tatt hensyn til andre mulige variabler.
Det følger imidlertid også at hvis du kun vil overføre data, vil det ikke være effektivt å bruke et maskinlesbart dokument til dette. Den bruker en modell, som i dette tilfellet er overflødig, den vil bare komme i veien. I tillegg, for å trekke ut kildedataene, må du skrive et program. Det er neppe noen vits i å bruke XML for noe som ikke vil bli formatert som et dokument på et eller annet tidspunkt (for eksempel ved å bruke CSS eller XSLT, eller begge deler), siden det er hovedgrunnen (om ikke den eneste) for å gjøre det. til dokumentmodellen.
Siden XML ikke har noe konsept for tall (eller boolske uttrykk eller andre datatyper), anses alle tall representert i dette formatet bare som tilleggstekst. For å trekke ut data, må skjemaet og dets forhold til de tilsvarende dataene som uttrykkes, være kjent. Du må også vite når, basert på konteksten, et bestemt tekstelement representerer et tall og skal konverteres til et tall osv.
Dermed er prosessen med å trekke ut data fra XML-dokumenter ikke så forskjellig fra prosessen med å gjenkjenne skannede dokumenter som inneholder for eksempel tabeller som danner mange sider med numeriske data. Ja, det er mulig å gjøre dette i prinsippet, men dette er ikke den mest optimale måten, bortsett fra som en siste utvei, når det absolutt ikke er andre alternativer. En rimelig løsning er å ganske enkelt finne en digital kopi av originaldata som ikke er innebygd i en dokumentmodell som kombinerer dataene med dens spesifikke tekstrepresentasjon.
Når det er sagt, overrasker det meg ikke i det hele tatt at XML er populært i næringslivet. Grunnen til dette er nettopp at dokumentformatet (på papir) er forståelig og kjent for næringslivet, og de ønsker å fortsette å bruke en kjent og forståelig modell. Av samme grunn bruker bedrifter altfor ofte PDF-dokumenter i stedet for mer maskinlesbare formater – fordi de fortsatt er knyttet til konseptet med en trykt side med en bestemt fysisk størrelse. Dette gjelder til og med dokumenter som neppe vil bli skrevet ut (for eksempel en 8000-siders PDF-fil med registerdokumentasjon). Fra dette synspunktet er bruken av XML i virksomheten i hovedsak en manifestasjon av skeuomorfisme. Folk forstår den metaforiske ideen om en trykt side av begrenset størrelse, og de forstår hvordan man lager forretningsprosesser basert på trykte dokumenter. Hvis det er guiden din, representerer dokumenter uten fysiske størrelsesbegrensninger som er maskinlesbare – XML-dokumenter – innovasjon samtidig som de er en kjent og komfortabel dokumentmotpart. Dette forhindrer ikke at de forblir en feilaktig og altfor skeuomorf måte å presentere data på.
Til dags dato er de eneste XML-skjemaene jeg vet om som jeg virkelig kan kalle en gyldig bruk av formatet XHTML og DocBook.
Kilde: www.habr.com