XML თითქმის ყოველთვის არასწორად გამოიყენება

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 სქემა, რაც კი ოდესმე მინახავს, იღებს ავტომატური უზრუნველყოფის კონფიგურაციის ფაილის ფორმატს Polycom IP ტელეფონის ტელეფონებისთვის. ასეთი ფაილები საჭიროებენ 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 დოკუმენტებს მანქანით წასაკითხი ფორმატების ნაცვლად - იმიტომ, რომ ისინი ჯერ კიდევ დაკავშირებულია კონკრეტული ფიზიკური ზომის დაბეჭდილი გვერდის კონცეფციასთან. ეს ეხება ისეთ დოკუმენტებსაც კი, რომლებიც საეჭვოა ოდესმე დაიბეჭდოს (მაგალითად, რეესტრის დოკუმენტაციის 8000 გვერდიანი PDF). ამ თვალსაზრისით, XML-ის გამოყენება ბიზნესში არსებითად სკეუმორფიზმის გამოვლინებაა. ადამიანებს ესმით შეზღუდული ზომის დაბეჭდილი გვერდის მეტაფორული იდეა და ესმით, როგორ შექმნან ბიზნეს პროცესები დაბეჭდილი დოკუმენტების საფუძველზე. თუ ეს თქვენი მეგზურია, დოკუმენტები ფიზიკური ზომის შეზღუდვის გარეშე, რომლებიც იკითხება მანქანით - XML ​​დოკუმენტები - წარმოადგენს ინოვაციებს, ხოლო დოკუმენტის ნაცნობი და კომფორტული კოლეგაა. ეს ხელს არ უშლის მათ დარჩეს მონაცემების წარმოდგენის არასწორი და ზედმეტად სკეუმორფული გზა.

დღემდე, ერთადერთი XML სქემები, რომელთა შესახებაც ვიცი, რომელთა შესახებაც ნამდვილად შემიძლია ვუწოდო ფორმატის სწორი გამოყენება, არის XHTML და DocBook.

წყარო: www.habr.com