XML demək olar ki, həmişə sui-istifadə olunur

XML demək olar ki, həmişə sui-istifadə olunur
XML dili 1996-cı ildə icad edilmişdir. O ortaya çıxan kimi onun tətbiqi imkanları artıq səhv başa düşülməyə başlamışdı və onların onu uyğunlaşdırmağa çalışdıqları məqsədlər üçün bu, ən yaxşı seçim deyildi.

Gördüyüm XML sxemlərinin böyük əksəriyyətinin XML-dən uyğun olmayan və ya səhv istifadə olduğunu söyləmək mübaliğə olmaz. Üstəlik, XML-in bu istifadəsi XML-in nə demək olduğunu əsaslı şəkildə başa düşmədiyini nümayiş etdirdi.

XML işarələmə dilidir. Bu məlumat formatı deyil. Əksər XML sxemləri bu fərqi açıq şəkildə nəzərdən qaçırmış, XML-i məlumat formatı ilə çaşdırmışdır ki, bu da son nəticədə XML-in seçimində səhvə səbəb olur, çünki əslində lazım olan məlumat formatıdır.

Çox təfərrüata varmadan, XML strukturu və metadata ilə mətn bloklarını şərh etmək üçün ən uyğundur. Əsas məqsədiniz mətn bloku ilə işləmək deyilsə, XML seçimini əsaslandırmaq mümkün deyil.

Bu nöqteyi-nəzərdən XML sxeminin nə dərəcədə düzgün qurulduğunu yoxlamağın sadə yolu var. Nümunə olaraq nəzərdə tutulan sxemdəki sənədi götürək və ondan bütün teqləri və atributları çıxaraq. Qalan şey mənasızdırsa (və ya boş sətir qalıbsa), ya sxeminiz düzgün qurulmayıb, ya da sadəcə XML-dən istifadə etməməli idiniz.

Aşağıda səhv qurulmuş sxemlərin ən ümumi nümunələrindən bəzilərini verəcəyəm.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Burada XML-də sadə açar-dəyər lüğətini ifadə etmək üçün əsassız və qəribə (çox geniş yayılmış olsa da) cəhdinin nümunəsini görürük. Bütün teqləri və atributları silsəniz, boş bir sıra qalacaqsınız. Əslində, bu sənəd nə qədər absurd səslənsə də, boş sətrin semantik annotasiyasıdır.

<root name="John" city="London" />

Vəziyyəti daha da pisləşdirmək üçün biz burada lüğəti ifadə etməyin ekstravaqant üsulu kimi boş sətirin sadəcə semantik annotasiyasına malik deyilik – bu dəfə “lüğət” birbaşa kök elementin atributları kimi kodlaşdırılıb. Bu, elementdə verilmiş atribut adları dəstini qeyri-müəyyən və dinamik edir. Üstəlik, bu, müəllifin həqiqətən ifadə etmək istədiyinin hamısının sadə açar-dəyər sintaksisi olduğunu göstərir, lakin bunun əvəzinə o, XML-i tətbiq etmək üçün tamamilə qəribə bir qərar qəbul edərək, atribut sintaksisini istifadə etmək üçün bir boş elementdən sadəcə bir prefiks kimi istifadə etməyə məcbur etdi. Və belə sxemlərə çox tez-tez rast gəlirəm.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Bu daha yaxşı bir şeydir, amma indi nədənsə açarlar metadatadır və dəyərlər deyil. Lüğətlərə çox qəribə baxış. Bütün teqləri və atributları silsəniz, məlumatın yarısı itiriləcək.

XML-də düzgün lüğət ifadəsi belə görünür:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Ancaq insanlar XML-dən məlumat formatı kimi istifadə etmək və sonra onu lüğət təşkil etmək üçün istifadə etmək barədə qəribə qərar veriblərsə, o zaman etdiklərinin yersiz və rahat olmadığını başa düşməlidirlər. Dizaynerlərin öz tətbiqlərini yaratmaq üçün səhvən XML seçmələri də adi haldır. Ancaq daha tez-tez, XML-in sadəcə olaraq bunun üçün uyğun olmadığını nəzərə almayaraq, yuxarıda təsvir olunan formalardan birində XML-dən mənasız istifadə etməklə vəziyyəti daha da pisləşdirirlər.

Ən pis XML sxemi? Yeri gəlmişkən, mükafat indiyə qədər gördüyüm ən pis XML sxemi, Polycom IP telefoniya telefonları üçün avtomatik təminat konfiqurasiya faylı formatını əldə edir. Bu cür fayllar TFTP vasitəsilə XML sorğu fayllarının yüklənməsini tələb edir ki, bu... Ümumiyyətlə, belə bir fayldan bir parçanı təqdim edirik:

<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="..." />

Bu kiminsə pis zarafatı deyil. Və bu mənim ixtiram deyil:

  • elementlər sadəcə olaraq iyerarxik adları olan atributları əlavə etmək üçün prefiks kimi istifadə olunur.
  • Müəyyən bir qeyd növünün bir neçə nümunəsinə dəyər təyin etmək istəyirsinizsə, bunu etmək üçün atribut adlarından istifadə etməlisiniz. indeksləri olan.
  • Bundan əlavə, ilə başlayan atributlar softkey., elementlər üzərində yerləşdirilməlidir <softkey/>, ilə başlayan atributlar feature., elementlər üzərində yerləşdirilməlidir <feature/> və s., tamamilə lazımsız və ilk baxışda mənasız görünməsinə baxmayaraq.
  • Və nəhayət, əgər siz atribut adının ilk komponentinin həmişə element adı ilə eyni olacağına ümid edirsinizsə - belə bir şey yoxdur! Məsələn, atributlar up. bağlanmalıdır <userpreferences/>. Elementlərə atribut adlarının əlavə edilməsi qaydası ixtiyaridir, demək olar ki, tamamilə.

Sənədlər və ya məlumatlar. Hərdən bir kimsə XML və JSON-u müqayisə etməyə çalışaraq tamamilə qəribə bir şey edir və beləliklə də başa düşmədiklərini göstərir. XML sənəd işarələmə dilidir. JSON strukturlaşdırılmış məlumat formatıdır, ona görə də onları bir-biri ilə müqayisə etmək isti ilə yumşaq müqayisə etməyə çalışmaq kimidir.

Aralarındakı fərq anlayışı sənədlər və məlumatlar. XML-in analoqu olaraq biz şərti olaraq maşınla oxuna bilən sənəd götürə bilərik. O, maşın oxunaqlı olması üçün nəzərdə tutulsa da, o, məcazi olaraq sənədlərə istinad edir və bu nöqteyi-nəzərdən faktiki olaraq PDF sənədləri ilə müqayisə oluna bilər, hansı ki, əksər hallarda maşın oxuna bilmir.

Məsələn, XML-də elementlərin sırası vacibdir. Lakin JSON-da obyektlər daxilində açar-dəyər cütlərinin sırası mənasız və qeyri-müəyyəndir. Əgər açar-dəyər cütlərinin sıralanmamış lüğətini əldə etmək istəyirsinizsə, həmin faylda elementlərin göründüyü faktiki sıranın əhəmiyyəti yoxdur. Ancaq bu məlumatlardan çoxlu müxtəlif növ məlumat yarada bilərsiniz. sənədlər, çünki sənəddə müəyyən qayda var. Metaforik olaraq, çap və ya PDF faylından fərqli olaraq fiziki ölçülərə malik olmasa da, kağız üzərində olan sənədin analoqudur.

Düzgün XML lüğət təqdimatı nümunəm JSON təmsilindən fərqli olaraq lüğətdəki elementlərin sırasını göstərir. Mən bu sıraya laqeyd qala bilmərəm: bu xəttilik sənəd modelinə və XML formatına xasdır. Bəziləri bu XML sənədini şərh edərkən əmrə məhəl qoymamağı seçə bilər, lakin bu barədə mübahisə etməyin mənası yoxdur, çünki məsələ formatın özünün müzakirəsi çərçivəsindən kənardadır. Üstəlik, sənədə kaskad üslub cədvəlini əlavə etməklə brauzerdə görünən hala gətirsəniz, lüğət elementlərinin müəyyən bir ardıcıllıqla və başqa heç bir şəkildə görünmədiyini görəcəksiniz.

Başqa sözlə, lüğətə (strukturlaşdırılmış məlumat parçası) çevrilə bilər n müxtəlif mümkün sənədlər (XML, PDF, kağız və s.), harada n - lüğətdəki elementlərin mümkün birləşmələrinin sayı və digər mümkün dəyişənləri hələ nəzərə almamışıq.

Bununla belə, bundan da belə nəticə çıxır ki, əgər siz yalnız məlumatları ötürmək istəyirsinizsə, bunun üçün maşın tərəfindən oxuna bilən sənəddən istifadə effektiv olmayacaq. O, bu halda artıq olan bir modeldən istifadə edir, o, yalnız yoluna mane olacaq. Bundan əlavə, mənbə məlumatlarını çıxarmaq üçün bir proqram yazmalısınız. Nə vaxtsa sənəd kimi formatlaşdırılmayacaq bir şey üçün (məsələn, CSS və ya XSLT və ya hər ikisindən istifadə etməklə) XML-dən istifadə etməyin heç bir mənası yoxdur, çünki bunu etməyin əsas (əgər yeganə deyilsə) səbəbi budur. sənəd modelinə.

Üstəlik, XML-də ədədlər (və ya Boolean ifadələri və ya digər məlumat növləri) anlayışı olmadığından, bu formatda təmsil olunan bütün nömrələr sadəcə əlavə mətn hesab olunur. Verilənləri çıxarmaq üçün sxem və onun ifadə olunan müvafiq verilənlərlə əlaqəsi məlum olmalıdır. Siz həmçinin bilməlisiniz ki, kontekstdən asılı olaraq konkret mətn elementi nə vaxt rəqəmi təmsil edir və nömrəyə çevrilməlidir və s.

Beləliklə, XML sənədlərindən məlumatların çıxarılması prosesi, məsələn, çox sayda ədədi məlumat səhifəsini təşkil edən cədvəlləri ehtiva edən skan edilmiş sənədlərin tanınması prosesindən o qədər də fərqlənmir. Bəli, prinsipcə bunu etmək mümkündür, lakin bu, ən optimal yol deyil, son çarə istisna olmaqla, tamamilə başqa variantlar olmadıqda. Ağlabatan bir həll, verilənləri xüsusi mətn təsviri ilə birləşdirən sənəd modelinə daxil edilməyən orijinal məlumatın sadəcə rəqəmsal surətini tapmaqdır.

Bununla belə, XML-in biznesdə populyar olması məni heç də təəccübləndirmir. Bunun səbəbi məhz sənəd formatının (kağız üzərində) başa düşülən və biznes üçün tanış olmasıdır və onlar tanış və başa düşülən modeldən istifadə etməyə davam etmək istəyirlər. Eyni səbəbdən, müəssisələr daha tez-tez maşınla oxuna bilən formatlar əvəzinə PDF sənədlərindən istifadə edirlər - çünki onlar hələ də müəyyən fiziki ölçüyə malik çap səhifəsi konsepsiyasına bağlıdırlar. Bu, hətta çap edilməsi mümkün olmayan sənədlərə də aiddir (məsələn, reyestr sənədlərinin 8000 səhifəlik PDF sənədi). Bu baxımdan biznesdə XML-dən istifadə mahiyyətcə skeuomorfizmin təzahürüdür. İnsanlar məhdud ölçülü çap edilmiş səhifənin metaforik ideyasını başa düşürlər və çap sənədləri əsasında iş proseslərini necə yaratmağı başa düşürlər. Əgər bu sizin bələdçinizdirsə, maşın tərəfindən oxuna bilən fiziki ölçü məhdudiyyəti olmayan sənədlər – XML sənədləri – tanış və rahat sənəd həmkarı olmaqla innovasiyanı təmsil edir. Bu, onların yanlış və həddindən artıq skeuomorfik məlumat təqdim etmə üsulu olaraq qalmasına mane olmur.

Bu günə qədər formatdan etibarlı istifadə adlandıra biləcəyim yeganə XML sxemləri XHTML və DocBook-dur.

Mənbə: www.habr.com

Добавить комментарий