Az XML nyelvet 1996-ban találták fel. Alighogy megjelent, alkalmazásának lehetőségeit már félreérteni kezdték, és arra a célra, amelyhez igazítani próbálták, nem volt a legjobb választás.
Nem túlzás azt állítani, hogy az általam látott XML-sémák túlnyomó többsége nem megfelelő vagy helytelen XML-használat volt. Ezen túlmenően, az XML ilyen használata azt mutatta, hogy alapvetően félreértik az XML lényegét.
Az XML egy jelölőnyelv. Ez nem adatformátum. A legtöbb XML-séma kifejezetten figyelmen kívül hagyta ezt a megkülönböztetést, összetévesztve az XML-t az adatformátummal, ami végül tévedéshez vezet az XML kiválasztásánál, mivel ez az adatformátum, amelyre valójában szükség van.
Anélkül, hogy túlságosan belemennénk a részletekbe, az XML a legalkalmasabb szövegblokkok struktúrával és metaadatokkal való megjegyzésére. Ha a fő célja nem az, hogy szövegtömbökkel dolgozzon, az XML választása valószínűleg nem indokolt.
Ebből a szempontból egyszerű módja van annak ellenőrzésére, hogy az XML-séma milyen jól készült. Vegyünk példaként egy dokumentumot a kívánt sémában, és távolítsunk el belőle minden címkét és attribútumot. Ha a megmaradtnak nincs értelme (vagy ha van egy üres sor), akkor vagy a séma nincs megfelelően felépített, vagy egyszerűen nem kellett volna XML-t használnia.
Az alábbiakban a helytelenül felépített áramkörök leggyakoribb példáit mutatom be.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Itt egy példát látunk egy alaptalan és furcsa (bár nagyon gyakori) kísérletre egy egyszerű kulcsérték szótár XML-ben való kifejezésére. Ha eltávolít minden címkét és attribútumot, akkor egy üres sor marad. Lényegében ez a dokumentum, bármennyire is abszurdnak hangzik, egy üres sor szemantikai megjegyzése.
<root name="John" city="London" />Tovább rontja a helyzetet, hogy itt nem csak egy üres karakterlánc szemantikai megjegyzése van a szótár kifejezésének extravagáns módjaként – ezúttal a „szótár” közvetlenül a gyökérelem attribútumaiként van kódolva. Ez meghatározatlanná és dinamikussá teszi az adott elem attribútumneveinek halmazát. Ráadásul azt mutatja, hogy a szerző valójában csak egy egyszerű kulcsérték szintaxist akart kifejezni, de ehelyett meghozta azt a teljesen bizarr döntést, hogy XML-t alkalmaz, és arra kényszerítette, hogy egyetlen üres elemet egyszerűen előtagként használjon az attribútum szintaxis használatához. És nagyon gyakran találkozom ilyen sémákkal.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Ez valami jobb, de most valamiért a kulcsok metaadatok, az értékek pedig nem. Nagyon furcsa pillantás a szótárakra. Ha eltávolít minden címkét és attribútumot, az információ fele elvész.
Egy helyes szótári kifejezés XML-ben valahogy így nézne ki:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>De ha az emberek azt a furcsa döntést hozták, hogy az XML-t használják adatformátumként, majd azt a szókincs rendezésére használják, akkor meg kell érteniük, hogy amit csinálnak, az nem megfelelő és nem kényelmes. Az is gyakori, hogy a tervezők tévedésből az XML-t választják alkalmazásaik létrehozásához. De még gyakrabban rontják a helyzetet, ha értelmetlenül használják az XML-t a fent leírt formák valamelyikében, figyelmen kívül hagyva azt a tényt, hogy az XML egyszerűen nem alkalmas erre.
A legrosszabb XML-séma? Mellesleg a díjat a legrosszabb XML séma, amit valaha láttam, Lekéri az automatikus kiépítési konfigurációs fájlformátumot a Polycom IP-telefonokhoz. Az ilyen fájlok TFTP-n keresztüli XML kérésfájlok letöltését igénylik, ami... Általánosságban elmondható, hogy itt van egy részlet egy ilyen fájlból:
<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="..." />Ez nem valaki rossz tréfája. És ez nem az én találmányom:
- Az elemek egyszerűen előtagként használhatók attribútumok csatolásához, amelyek maguk is hierarchikus elnevezéssel rendelkeznek.
- Ha egy adott típusú rekord több példányához szeretne értékeket rendelni, akkor ehhez attribútumneveket kell használnia. amelyek indexekkel rendelkeznek.
- Ezen kívül a következővel kezdődő attribútumok
softkey., elemekre kell helyezni<softkey/>, attribútumok kezdve afeature., elemekre kell helyezni<feature/>stb., annak ellenére, hogy teljesen feleslegesnek és első pillantásra értelmetlennek tűnik. - És végül, ha azt reméli, hogy egy attribútum nevének első összetevője mindig ugyanaz lesz, mint az elem neve – semmi ilyesmi! Például attribútumok
up.csatolni kell<userpreferences/>. Az attribútumnevek elemekhez csatolásának sorrendje tetszőleges, szinte teljesen.
Dokumentumok vagy adatok. Időnként valaki valami egészen furcsát tesz, amikor megpróbálja összehasonlítani az XML-t és a JSON-t – és ezzel megmutatja, hogy egyiket sem érti. Az XML egy dokumentumleíró nyelv. A JSON egy strukturált adatformátum, így összehasonlításuk olyan, mintha a meleget a lágyal hasonlítaná össze.
közötti különbség fogalma dokumentumokat és adatokat. Az XML analógjaként feltételesen vehetünk egy géppel olvasható dokumentumot. Bár géppel olvashatónak szánják, metaforikusan utal a dokumentumokra, és ebből a szempontból tulajdonképpen a PDF dokumentumokhoz hasonlítható, amelyek legtöbbször géppel nem olvashatók.
Például az XML-ben az elemek sorrendje számít. A JSON-ban azonban a kulcs-érték párok sorrendje az objektumon belül értelmetlen és meghatározatlan. Ha a kulcs-érték párok rendezetlen szótárát szeretné megszerezni, akkor nem számít, hogy az elemek milyen sorrendben jelennek meg a fájlban. De ezekből az adatokból sokféle adatot képezhet. dokumentumok, mert van egy bizonyos sorrend a dokumentumban. Átvitt értelemben analóg egy papíron lévő dokumentummal, bár fizikai méretei nincsenek, ellentétben a nyomtatott vagy PDF-fájllal.
A megfelelő XML-szótár-ábrázolásra vonatkozó példám a szótár elemeinek sorrendjét mutatja, szemben a JSON-ábrázolással. Nem hagyhatom figyelmen kívül ezt a sorrendet: ez a linearitás a dokumentummodell és az XML formátum velejárója. Egyesek úgy dönthetnek, hogy figyelmen kívül hagyják a sorrendet ennek az XML-dokumentumnak az értelmezésekor, de nincs értelme ezen vitatkozni, mivel a kérdés túlmutat magának a formátumnak a tárgyalásán. Sőt, ha a dokumentumot a böngészőben megtekinthetővé teszi úgy, hogy egy lépcsőzetes stíluslapot csatol hozzá, látni fogja, hogy a szótárelemek meghatározott sorrendben jelennek meg, és nem másban.
Más szavakkal, egy szótár (egy strukturált adat) átalakítható n különféle lehetséges dokumentumok (XML, PDF, papír stb.), ahol n - a szótár lehetséges elemkombinációinak számát, és a többi lehetséges változót még nem vettük figyelembe.
Ebből azonban az is következik, hogy ha csak adatokat szeretnénk átvinni, akkor erre a géppel olvasható dokumentum használata nem lesz hatékony. Modellt használ, ami ebben az esetben fölösleges, csak az útjába kerül. Ezenkívül a forrásadatok kinyeréséhez egy programot kell írnia. Aligha van értelme XML-t használni olyan dolgokhoz, amelyek valamikor nem lesznek megformázva dokumentumként (mondjuk CSS vagy XSLT, vagy mindkettő), mivel ez a fő (ha nem az egyetlen) oka ennek. a dokumentummodellhez.
Sőt, mivel az XML nem tartalmaz számfogalmat (vagy logikai kifejezéseket vagy egyéb adattípusokat), az ebben a formátumban megjelenített összes szám csak kiegészítő szövegnek minősül. Az adatok kinyeréséhez ismerni kell a sémát és kapcsolatát a megfelelő kifejezett adatokkal. Azt is tudnia kell, hogy a kontextus alapján egy adott szövegelem mikor jelent számot, és mikor kell számmá alakítani stb.
Így az XML dokumentumokból származó adatok kinyerésének folyamata nem különbözik annyira a beszkennelt dokumentumok felismerésének folyamatától, amelyek például sok oldalnyi numerikus adatot tartalmazó táblázatokat tartalmaznak. Igen, ezt elvileg meg lehet tenni, de ez nem a legoptimálisabb módja, kivéve végső esetben, amikor egyáltalán nincs más lehetőség. Ésszerű megoldás, ha egyszerűen megkeresi az eredeti adatok digitális másolatát, amely nincs beágyazva egy dokumentummodellbe, amely egyesíti az adatokat a sajátos szöveges megjelenítésével.
Ennek ellenére egyáltalán nem lep meg, hogy az XML népszerű az üzleti életben. Ennek éppen az az oka, hogy a dokumentumok (papíron) formátuma érthető és ismerős a vállalkozások számára, és továbbra is egy megszokott és érthető modellt kívánnak alkalmazni. Ugyanezen okból a vállalkozások túl gyakran használnak PDF-dokumentumokat a géppel olvashatóbb formátumok helyett – mivel ezek még mindig a meghatározott fizikai méretű nyomtatott oldal fogalmához kötődnek. Ez még azokra a dokumentumokra is vonatkozik, amelyeket valószínűleg soha nem fognak kinyomtatni (például egy 8000 oldalas nyilvántartási dokumentáció PDF-fájlja). Ebből a szempontból az XML üzleti felhasználása alapvetően a skeuomorfizmus megnyilvánulása. Az emberek megértik a korlátozott méretű nyomtatott oldal metaforikus gondolatát, és megértik, hogyan lehet nyomtatott dokumentumok alapján üzleti folyamatokat létrehozni. Ha ez az útmutató, a fizikai méretkorlátozás nélküli, géppel olvasható dokumentumok – XML-dokumentumok – újdonságot képviselnek, miközben ismerős és kényelmes dokumentumokat jelentenek. Ez nem akadályozza meg őket abban, hogy az adatok hibás és túlzottan skeuomorf módját használják.
A mai napig az egyetlen olyan XML-sémát ismerek, amelyet valóban a formátum érvényes használatának nevezhetek, az az XHTML és a DocBook.
Forrás: will.com