Јазикот 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.
Извор: www.habr.com