КСМЛ језик је измишљен 1996. године. Тек што се појавио, могућности његове примене су већ почеле да се погрешно схватају, а за сврхе којима су покушавали да га прилагоде није био најбољи избор.
Није претеривање рећи да је велика већина КСМЛ шема које сам видео неприкладна или нетачна употреба КСМЛ-а. Штавише, ова употреба КСМЛ-а је показала фундаментално неразумевање о чему се ради у КСМЛ-у.
КСМЛ је језик за означавање. Ово није формат података. Већина КСМЛ шема је експлицитно превидела ову разлику, бркајући КСМЛ са форматом података, што на крају доводи до грешке у избору КСМЛ-а јер је то формат података који је заправо потребан.
Без улажења у превише детаља, КСМЛ је најпогоднији за означавање блокова текста структуром и метаподацима. Ако ваш главни циљ није да радите са блоком текста, избор КСМЛ-а вероватно неће бити оправдан.
Са ове тачке гледишта, постоји једноставан начин да проверите колико је КСМЛ шема добро направљена. Узмимо као пример документ у намераваној шеми и уклонимо све ознаке и атрибуте из њега. Ако оно што је остало нема смисла (или ако је остао празан ред), онда или ваша шема није правилно направљена или једноставно нисте требали користити КСМЛ.
У наставку ћу навести неке од најчешћих примера нетачно конструисаних кола.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Овде видимо пример неоснованог и чудног (мада веома уобичајеног) покушаја да се изрази једноставан речник кључ/вредност у КСМЛ-у. Ако уклоните све ознаке и атрибуте, остаће вам празан ред. У суштини, овај документ је, ма колико апсурдно звучао, семантичка анотација празног реда.
<root name="John" city="London" />Да ствар буде гора, овде немамо само семантичку белешку празног низа као екстравагантан начин изражавања речника – овог пута је „речник“ директно кодиран као атрибути основног елемента. Ово чини дати скуп имена атрибута на елементу недефинисаним и динамичким. Штавише, показује да је све што је аутор заиста желео да изрази била једноставна синтакса кључ/вредност, али је уместо тога донео апсолутно бизарну одлуку да примени КСМЛ, приморавајући употребу једног празног елемента једноставно као префикса за коришћење синтаксе атрибута. И врло често наилазим на такве шеме.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Ово је нешто боље, али сада су кључеви из неког разлога метаподаци, а вредности нису. Веома чудан поглед на речнике. Ако уклоните све ознаке и атрибуте, половина информација ће бити изгубљена.
Исправан речнички израз у КСМЛ-у би изгледао отприлике овако:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Али ако су људи донели чудну одлуку да користе КСМЛ као формат података, а затим га користе за организовање речника, онда би требало да схвате да је оно што раде неприкладно и није згодно. Такође је уобичајено да дизајнери грешком изаберу КСМЛ за креирање својих апликација. Али још чешће, они погоршавају ствари бесмисленим коришћењем КСМЛ-а у једном од горе описаних облика, занемарујући чињеницу да КСМЛ једноставно није погодан за ово.
Најгора КСМЛ шема? Иначе, награда за најгора КСМЛ шема коју сам икада видео, Добија формат датотеке конфигурације за аутоматску доделу за телефоне Полицом ИП телефоније. Такве датотеке захтевају преузимање датотека КСМЛ захтева преко ТФТП-а, што... Генерално, ево извода из једне такве датотеке:
<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/>. Редослед додавања имена атрибута елементима је произвољан, скоро у потпуности.
Документи или подаци. С времена на време, неко уради нешто потпуно чудно покушавајући да упореди КСМЛ и ЈСОН—и тиме показује да ни они не разумеју. КСМЛ је језик за означавање докумената. ЈСОН је формат структурираних података, тако да је њихово поређење једно са другим као да покушавате да упоредите топло са меким.
Концепт разлике између докумената и података. Као аналог КСМЛ-а, условно можемо узети машински читљив документ. Иако је предвиђено да буде машински читљив, он се метафорички односи на документе, и са ове тачке гледишта је заправо упоредив са ПДФ документима, који најчешће нису машински читљиви.
На пример, у КСМЛ-у је важан редослед елемената. Али у ЈСОН-у, редослед парова кључ-вредност унутар објеката је бесмислен и недефинисан. Ако желите да добијете неуређени речник парова кључ/вредност, стварни редослед у коме се елементи појављују у тој датотеци није битан. Али од ових података можете формирати много различитих типова података. докумената, јер постоји одређени ред у документу. Метафорички, аналогно је документу на папиру, иако нема физичке димензије, за разлику од исписа или ПДФ датотеке.
Мој пример правилне КСМЛ речничке репрезентације показује редослед елемената у речнику, за разлику од ЈСОН репрезентације. Не могу да занемарим овај редослед: ова линеарност је инхерентна моделу документа и КСМЛ формату. Неки ће можда одлучити да игноришу редослед када тумаче овај КСМЛ документ, али нема смисла расправљати о овоме јер је ово питање изван оквира дискусије о самом формату. Штавише, ако документ учините видљивим у претраживачу тако што ћете му приложити каскадну листу стилова, видећете да се елементи речника појављују одређеним редоследом и ни у ком другом.
Другим речима, речник (део структурираних података) се може конвертовати у n разни могући документи (у КСМЛ, ПДФ, папир итд.), где n - број могућих комбинација елемената у речнику, а остале могуће варијабле још нисмо узели у обзир.
Међутим, такође следи да ако желите да пренесете само податке, онда коришћење машински читљивог документа за ово неће бити ефикасно. Користи модел, који је у овом случају сувишан, само ће стати на пут. Поред тога, да бисте издвојили изворне податке, мораћете да напишете програм. Готово да нема смисла користити КСМЛ за нешто што у неком тренутку неће бити форматирано као документ (рецимо, коришћењем ЦСС-а или КССЛТ-а, или обоје), пошто је то главни (ако не и једини) разлог за то. на модел документа.
Штавише, пошто КСМЛ нема концепт бројева (или Булових израза, или других типова података), сви бројеви представљени у овом формату сматрају се само додатним текстом. Да бисте издвојили податке, шема и њен однос са одговарајућим подацима који се изражавају морају бити познати. Такође морате да знате када, на основу контекста, одређени текстуални елемент представља број и треба да се конвертује у број итд.
Дакле, процес издвајања података из КСМЛ докумената није толико различит од процеса препознавања скенираних докумената који садрже, на пример, табеле које формирају много страница нумеричких података. Да, то је у принципу могуће учинити, али ово није најоптималнији начин, осим у крајњем случају, када апсолутно нема других опција. Разумно решење је једноставно пронаћи дигиталну копију оригиналних података која није уграђена у модел документа који комбинује податке са њиховим специфичним текстуалним приказом.
Међутим, уопште ме не чуди што је КСМЛ популаран у пословању. Разлог томе је управо то што је формат документа (на папиру) разумљив и познат пословном окружењу, а они желе да наставе да користе познати и разумљив модел. Из истог разлога, предузећа пречесто користе ПДФ документе уместо машински читљивих формата – јер су и даље везани за концепт штампане странице са специфичном физичком величином. Ово се чак односи и на документе за које је мало вероватно да ће икада бити одштампани (на пример, ПДФ од 8000 страница документације регистра). Са ове тачке гледишта, употреба КСМЛ-а у пословању је у суштини манифестација скеуоморфизма. Људи разумеју метафоричку идеју штампане странице ограничене величине и разумеју како да креирају пословне процесе на основу штампаних докумената. Ако је то ваш водич, документи без ограничења физичке величине који су машински читљиви — КСМЛ документи — представљају иновацију док су познати и удобни пандан документу. То их не спречава да остану нетачан и претерано скеуоморфан начин представљања података.
До данас, једине КСМЛ шеме за које знам и које заиста могу назвати ваљаном употребом формата су КСХТМЛ и ДоцБоок.
Извор: ввв.хабр.цом