Мова XML была вынайдзена ў 1996 годзе. Ледзь ён паспеў з'явіцца, як магчымасці яго прымянення ўжо пачалі разумець няправільна, і для тых мэт, да якіх яго спрабавалі адаптаваць, ён быў не лепшым выбарам.
Не будзе перабольшаннем сказаць, што пераважная большасць схем XML, якія мне даводзілася бачыць, уяўлялі сабой немэтазгоднае ці няправільнае выкарыстанне XML. Больш за тое, такое ўжыванне XML сведчыла аб фундаментальным неразуменні таго, чым першым чынам з'яўляецца XML.
XML - гэта мова разметкі. Гэта не фармат дадзеных. У большасці схем XML гэтае размежаванне відавочна не ўлічвалі, блытаючы XML з фарматам дадзеных, што ў выніку азначала памылку ў самім выбары XML, паколькі насамрэч патрэбен быў менавіта фармат дадзеных.
Калі не ўдавацца ў дэталі, XML лепш за ўсё падыходзіць для анатавання блокаў тэксту са структурай і метададзенымі. Калі вашай галоўнай задачай не з'яўляецца праца з блокам тэксту, выбар XML ці наўрад будзе апраўданы.
З гэтага пункта гледжання існуе просты спосаб праверыць, наколькі добра зроблена схема XML. Возьмем для прыкладу дакумент у меркаванай схеме і выдалім з яго ўсе тэгі і атрыбуты. Калі ў тым, што засталося, няма сэнсу (ці калі застаўся пусты радок), то або ваша схема пабудавана няправільна, або вам проста не каштавала ўжываць XML.
Далей я прывяду некалькі найболей часта сустракаемых прыкладаў няправільна пабудаваных схем.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Тут мы бачым прыклад неабгрунтаванай і дзіўнай (хоць і вельмі распаўсюджанай) спробы выказаць мовай XML просты слоўнік "ключ-значэнне". Калі выдаліць усе тэгі і атрыбуты, застанецца пусты радок. Па сутнасці гэты дакумент уяўляе сабой, як бы абсурдна гэта ні гучала, семантычную анатацыю пустога радка.
<root name="John" city="London" />Што яшчэ горш, у нас тут не проста семантычная анатацыя пустога радка як экстравагантны спосаб выраза слоўніка - гэтым разам "слоўнік" напроста закадаваны ў выглядзе атрыбутаў каранёвага элемента. З-за гэтага зададзены набор імёнаў атрыбутаў на элеменце становіцца нявызначаным і дынамічным. Больш за тое, адсюль відаць, што ўсё, што на самой справе хацеў выказаць аўтар, - гэта просты сінтаксіс "ключ-значэнне", але замест гэтага ён прыняў абсалютна дзіўнае рашэнне прымяніць XML, прымусова задаючы выкарыстанне адзіночнага пустога элемента проста ў якасці прэфікса для выкарыстання. сінтаксісу атрыбутаў. І такія схемы трапляюцца мне часта.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Гэта ўжо сёе-тое лепей, але зараз ключы па нейкай прычыне з'яўляюцца метададзенымі, а значэння – не. Вельмі дзіўны погляд на слоўнікі. Калі выдаліць усе тэгі і атрыбуты, будзе страчана палова інфармацыі.
Правільны выраз слоўніка ў XML будзе выглядаць прыблізна так:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Але калі людзі прынялі дзіўнае рашэнне прымяняць XML як фармат дадзеных і затым з дапамогай яго парадкаваць слоўнік, то яны павінны разумець, што тое, што яны робяць недарэчна і не зручна. Яшчэ часта праекціроўшчыкі памылкова выбіраюць XML для стварэння сваіх прыкладанняў. Але яшчэ гушчару яны пагаршаюць сітуацыю бессэнсоўным ужываннем XML у адной з апісаных вышэй формаў, ігнаруючы той факт, што XML для гэтага проста не падыходзіць.
Самая горшая схема XML? Дарэчы, прыз за самую горшую схему XML, якую мне даводзілася бачыць, атрымлівае фармат файла канфігурацыі аўтаматычнага выдзялення рэсурсаў для тэлефонаў IP-тэлефаніі Polycom. Такія файлы патрабуюць загрузкі XML-файлаў запыту па TFTP, якія… Увогуле, вось урывак з аднаго такога файла:
<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="..." />Гэта не чыйсьці няўдалы жарт. І гэта не мая выдумка:
- элементы проста выкарыстоўваюцца як прэфікс для прымацавання атрыбутаў, якія самі па сабе маюць іерархічныя імёны.
- Калі трэба прыпісаць значэнні некалькім асобнікам запісу вызначанага выгляду, для гэтага неабходна выкарыстоўваць імёны атрыбутаў, у якіх ёсць індэксы.
- Акрамя гэтага, атрыбуты, якія пачынаюцца з
softkey., трэба змяшчаць на элементы<softkey/>, атрыбуты, якія пачынаюцца зfeature., трэба змяшчаць на элементы<feature/>і г. д., нягледзячы на тое, што гэта выглядае зусім залішнім і на першы погляд бессэнсоўным. - І, нарэшце, калі вы спадзяваліся, што першы кампанент імя атрыбута заўсёды супадае з імем элемента - нічога падобнага! Напрыклад, атрыбуты
up.павінны прымацоўвацца да<userpreferences/>. Парадак прымацавання імёнаў атрыбутаў да элементаў - адвольны, прычым практычна цалкам.
Дакументы ці дадзеныя. Час ад часу хтосьці робіць абсалютна дзіўныя рэчы, спрабуючы параўноўваць XML і JSON, - і тым самым паказваючы, што не разумее ні таго, ні іншага. XML - гэта мова разметкі дакументаў. JSON жа ўяўляе сабой фармат структураваных дадзеных, так што параўноўваць іх сябар з сябрам - усё роўна што спрабаваць параўнаць цёплае з мяккім.
Разабрацца ў гэтым дапаможа паняцце розніцы паміж дакументамі і дадзенымі. У якасці аналогу XML можна ўмоўна ўзяць машыначытальны дакумент. Хоць ён і прызначаны для счытвання машынай, метафарычна ён ставіцца да дакументаў, і з гэтага пункта гледжання фактычна з'яўляецца супастаўным з дакументамі фармату PDF, якія часцей за ўсё не з'яўляюцца машыначытальнымі.
Напрыклад, у XML мае значэнне парадак элементаў. А ў JSON парадак прытрымлівання пар «ключ-значэнне» усярэдзіне аб'ектаў не мае сэнсу і не вызначаны. Калі вы жадаеце атрымаць неўпарадкаваны слоўнік з пар "ключ-значэнне", фактычны парадак, у якім ідуць элементы ў гэтым файле, не мае значэння. Але вы можаце сфарміраваць з гэтых дадзеных шмат розных дакументаў, паколькі ў дакуменце ёсць пэўны парадак. Метафарычна гэта аналаг дакумента на паперы, хоць ён і не мае фізічных памераў у адрозненне ад раздрукоўкі ці файла PDF.
У маім прыкладзе правільнага падання слоўніка на мове XML паказаны парадак прытрымлівання элементаў у слоўніку, у адрозненне ад падання на мове JSON. Я не магу ігнараваць гэты парадак: такая лінейнасць першапачаткова ўласцівая мадэлі дакументаў і фармату XML. Хтосьці пры інтэрпрэтацыі гэтага XML-дакумента можа вырашыць праігнараваць парадак, але спрачацца наконт гэтага бессэнсоўна, паколькі дадзенае пытанне выходзіць за рамкі абмеркавання ўласна фармату. Больш таго, калі зрабіць дакумент які праглядаецца ў браўзэры, прымацаваўшы да яго каскадную табліцу стыляў, можна будзе ўбачыць, што элементы слоўніка вынікаюць у вызначаным парадку, і ні ў якім іншым.
Іншымі словамі, слоўнік (фрагмент структураваных дадзеных) можа быць пераўтвораны ў n розных магчымых дакументаў (у фармаце XML, PDF, на паперы і т. п.), дзе n - колькасць магчымых камбінацый элементаў у слоўніку, і гэта мы яшчэ не ўлічылі іншыя магчымыя зменныя.
Разам з тым з гэтага таксама вынікае, што калі вы хочаце перадаць адны толькі даныя, то выкарыстоўваць для гэтага машыначытальны дакумент будзе не эфектыўна. У ім выкарыстоўваецца мадэль, якая ў гэтым выпадку лішняя, яна будзе толькі мяшаць. Да таго ж, для таго каб атрымаць зыходныя дадзеныя, неабходна будзе напісаць праграму. Ці наўрад ёсць сэнс выкарыстаць XML для чагосьці такога, што на вызначаным этапе не будзе фарматавацца ў выглядзе дакумента (скажам, з дапамогай CSS або XSLT, альбо і таго, і іншага), паколькі гэта галоўная (калі не адзіная) чыннік для таго , Каб прытрымлівацца мадэлі дакумента.
Больш за тое, паколькі ў XML няма паняцця лікаў (ці булевых выразаў, ці іншых тыпаў дадзеных), усе прадстаўленыя ў гэтым фармаце лічбы лічацца толькі дадатковым тэкстам. Для вымання дадзеных павінна быць вядомая схема і яе сувязь з адпаведнымі дадзенымі. Таксама неабходна ведаць, калі зыходзячы з кантэксту той ці іншы элемент тэксту ўяўляе сабою лік, і яго варта ператвараць у лік, і т. д.
Такім чынам, працэс вымання дадзеных з дакументаў XML не так ужо моцна адрозніваецца ад працэсу распазнання адсканаваных дакументаў, утрымоўвальных, напрыклад, табліцы, утваральныя мноства старонак лікавых дадзеных. Так, зрабіць гэта ў прынцыпе магчыма, але гэта не самы аптымальны шлях, - хіба што ў крайнім выпадку, калі зусім няма іншых варыянтаў. Разумным рашэннем будзе проста знайсці лічбавую копію арыгінальных дадзеных, не закладзеных у мадэль дакумента, у якой дадзеныя аб'яднаны з іх канкрэтным тэкставым прадстаўленнем.
Пры гэтым мяне зусім не дзівіць, што XML папулярны ў бізнэсе. Чыннік гэтага менавіта ў тым, што фармат дакументаў (на паперы) зразумелы і звыклы для бізнэсу, і тамака жадаюць працягваць карыстацца знаёмай і зразумелай мадэллю. Па тым жа самым чынніку ў бізнэсе занадта часта выкарыстаюць дакументы ў PDF замест зручнейшых для машыннай апрацоўкі фарматаў — таму што яны па-ранейшаму прывязаныя да паняцця друкаванай старонкі з вызначаным фізічным памерам. Гэта датычыцца нават тых дакументаў, якія наўрад ці калі-небудзь будуць раздрукоўвацца (напрыклад, PDF-файл дакументацыі рэестра з 8000 старонак). З гэтага пункту гледжання выкарыстанне XML у бізнэсе па сутнасці – праява скевамарфізму. Людзям зразумелая метафарычная ідэя друкаванай старонкі абмежаванага памеру, і яны разумеюць, як ствараць бізнэс-працэсы на аснове друкаваных дакумэнтаў. Калі гэта ваш арыенцір, дакументы без абмежаванага фізічнага памеру, якія з'яўляюцца машыначытальнымі - дакументы XML - уяўляюць сабой інавацыю, з'яўляючыся пры гэтым знаёмым і камфортным аналагам дакумента. Што не мяшае ім заставацца няслушным і залішне скевоморфічным спосабам падання дадзеных.
На сённяшні дзень адзінымі вядомымі мне схемамі XML, якія я сапраўды магу назваць правільным ужываннем гэтага фармату, з'яўляюцца XHTML і DocBook.
Крыніца: habr.com