XML — სრული ქართულენოვანი გზამკვლევი

ეს არის სრული სასწავლო წიგნი XML-ზე — ნულიდან, წინასწარი ცოდნის გარეშე. გაიგებ რა არის XML, რატომ შეიქმნა, რა პრობლემებს ჭრის და რატომ რჩება დღემდე ინდუსტრიის სტანდარტად — JSON-ის პოპულარობის მიუხედავად.

თითო თავი მოიცავს ახსნას, ცოცხალ XML მაგალითებს, რეალურ ბიზნეს-მაგალითებს, სავარჯიშოებს, ქვიზებს და შეჯამებას.

10 თავი 85 თემა 10 თავი + ქვიზები

1 📘 შესავალი XML-ში

XML (eXtensible Markup Language) არის მონაცემთა აღწერისა და სტრუქტურირების უნივერსალური ენა. ამ თავში გავიგებთ რა არის XML, საიდან წარმოიშვა, რა პრობლემებს ჭრის და როგორ განსხვავდება plain text-ის, HTML-ისა და JSON-ისგან.

XML W3C სტანდარტი

რა არის XML

XML ნიშნავს eXtensible Markup Language — „გაფართოებად მარკირების ენას". ეს არის წესების ნაკრები, რომლითაც მონაცემს ვწერთ ისე, რომ ის ერთდროულად წაიკითხოს ადამიანმაც და კომპიუტერმაც.

XML თავად არაფერს აკეთებს — ის არ არის პროგრამული ენა, არ ითვლის, არ ხატავს. XML მხოლოდ აღწერს მონაცემს: რა არის ეს მონაცემი და როგორ არის ის ორგანიზებული. სწორედ ამიტომ XML-ს უწოდებენ „თვით-აღმწერ" (self-describing) ფორმატს — ტეგების სახელები თავადვე ხსნიან, რა იმალება მათ შიგნით.

სიტყვა „გაფართოებადი" (eXtensible) ნიშნავს, რომ ტეგებს თავად ვიგონებთ. HTML-ში ტეგები ფიქსირებულია (<p>, <div>), XML-ში კი შენ ქმნი იმ ტეგებს, რომლებიც შენს მონაცემს მიესადაგება: <ფასი>, <მომხმარებელი>, <invoice>.

მაგალითები

პირველი XML დოკუმენტი

მარტივი შენიშვნა (note). შენიშნე — ტეგების სახელები თავად ხსნიან შინაარსს.

XML

<?xml version="1.0" encoding="UTF-8"?>
<note>
  <to>თამარი</to>
  <from>გიორგი</from>
  <heading>შეხსენება</heading>
  <body>არ დაგავიწყდეს შეხვედრა ხუთშაბათს!</body>
</note>

💡 რჩევა: დაიმახსოვრე: XML აღწერს მონაცემს, არ ამუშავებს მას. დამუშავება პროგრამის (PHP, Java, JavaScript...) საქმეა.

🌍 რეალური გამოყენება

XML-ს დღესაც იყენებენ ყველგან: Microsoft Office-ის ფაილები (.docx, .xlsx), RSS არხები, Android-ის layout-ები, SOAP ვებ-სერვისები, Maven/Spring კონფიგურაციები და ათასობით საწარმოო სისტემა.

რატომ XML?

რატომ შეიქმნა XML — რა პრობლემას ჭრის

დააკვირდი პრობლემას: ორ სხვადასხვა კომპანიის პროგრამას სჭირდება მონაცემების გაცვლა. ერთი დაწერილია Java-ზე და მუშაობს Linux-ზე, მეორე — C#-ზე და Windows-ზე. როგორ გადასცეს ერთმა მეორეს „შეკვეთა"?

თუ თითოეული თავის ფორმატს გამოიგონებს, მივიღებთ ქაოსს — ყველა ყველასთან ცალკე უნდა „შეთანხმდეს". XML-მა შესთავაზა ერთი, ნეიტრალური, ტექსტური ფორმატი, რომელსაც ნებისმიერი ენა და სისტემა კითხულობს.

XML წყვეტს კონკრეტულ პრობლემებს:

თავსებადობა (interoperability): განსხვავებული პლატფორმები ერთმანეთს „ესაუბრებიან".
სტრუქტურა: მონაცემს აქვს მკაფიო, იერარქიული ფორმა.
თვით-აღწერადობა: ფაილი თავადვე ხსნის რას შეიცავს.
ვალიდაცია: სქემით (DTD/XSD) შეგვიძლია ვამოწმოთ მონაცემი სწორია თუ არა.
დამოუკიდებლობა: XML უბრალო ტექსტია — არ არის მიბმული არც ერთ კონკრეტულ პროგრამაზე ან OS-ზე.

💡 რჩევა: XML-ის მთავარი იდეა: „ერთხელ შეთანხმდი ფორმატზე — და აღარასოდეს გამოიგონო ბორბალი თავიდან". ეს არის სტანდარტიზაციის ძალა.

ისტორია

XML-ის ისტორია

XML ერთ დღეს არ გამოჩენილა — მას წინ უძღვის ათწლეულების გამოცდილება.

1960-70-იანი: IBM-ში იქმნება GML, შემდეგ SGML (Standard Generalized Markup Language) — ძალიან ძლიერი, მაგრამ ურთულესი ენა დიდი დოკუმენტებისთვის.
1991: SGML-ის საფუძველზე იქმნება HTML — გამარტივებული, ვებ-გვერდებისთვის.
1996-1998: W3C-მ (World Wide Web Consortium) აიღო SGML-ის სიძლიერე, მოაჭრა სირთულე და შექმნა XML 1.0. ოფიციალური რეკომენდაცია — 1998 წლის 10 თებერვალი.
2000-იანები: XML-ის „ოქროს ხანა" — SOAP, AJAX (თავდაპირველად XML-ით), Office Open XML, კონფიგურაციები.
2006-დან: ვებ-API-ებში JSON იკიდებს ფეხს, მაგრამ XML რჩება საწარმოო და დოკუმენტურ სფეროებში.

XML არ არის „მოძველებული" — ის არის დამდგარი (mature) სტანდარტი, რომელმაც მნიშვნელოვნად ჩამოაყალიბა თანამედროვე მონაცემთა გაცვლის პრაქტიკა.

💡 რჩევა: XML SGML-ის „გამოხდილი" ვერსიაა: ~80% სიძლიერე, ~20% სირთულე. HTML და XML „და-ძმები" არიან — ორივე SGML-დან.

XML vs plain text

XML vs. უბრალო ტექსტი (plain text)

რატომ არ ვწეროთ მონაცემი უბრალოდ ტექსტად, მძიმეებით გამოყოფილი (CSV)?

დააკვირდი ამ CSV-ს: გიორგი,25,თბილისი. რას ნიშნავს 25? ასაკი? წონა? შეკვეთების რაოდენობა? ტექსტი არაფერს ხსნის. ასევე — თუ მისამართში მძიმე იქნება, მთელი სტრუქტურა ირღვევა.

XML-ში თითოეულ მნიშვნელობას აქვს სახელი (ტეგი) და მკაფიო საზღვრები. მონაცემი თვით-აღწერადია და იერარქიული.

მნიშვნელობები

მნიშვნელობა	აღწერა
`plain text / CSV`	კომპაქტური, მაგრამ კონტექსტის გარეშე; ბრტყელი (იერარქია არ აქვს); მსხვრევადი (გამყოფი სიმბოლო თუ მონაცემშია — ირღვევა).
`XML`	უფრო მოცულობითი, მაგრამ თვით-აღწერადი, იერარქიული, ვალიდირებადი და მდგრადი.

მაგალითები

იგივე მონაცემი — CSV (გაუგებარი)

CSV

გიორგი,25,თბილისი,2

იგივე მონაცემი — XML (ცხადი)

XML

<მომხმარებელი>
  <სახელი>გიორგი</სახელი>
  <ასაკი>25</ასაკი>
  <ქალაქი>თბილისი</ქალაქი>
  <შეკვეთები>2</შეკვეთები>
</მომხმარებელი>

💡 რჩევა: CSV კარგია მარტივი, ბრტყელი ცხრილებისთვის. XML — როცა მონაცემს აქვს სტრუქტურა, ჩალაგება (nesting) ან მნიშვნელობა სჭირდება ახსნა.

XML vs HTML

XML vs. HTML

XML და HTML გარეგნულად ჰგვანან (ორივეს ტეგები აქვს), მაგრამ სხვადასხვა მიზანს ემსახურებიან.

HTML აღწერს, როგორ გამოჩნდეს მონაცემი ეკრანზე (ვიზუალიზაცია).
XML აღწერს, რა არის მონაცემი (სტრუქტურა და შინაარსი).

HTML-ში ტეგები წინასწარ განსაზღვრულია და მათი დანიშნულება გარეგნობაა. XML-ში ტეგებს თავად ვქმნით და მათი დანიშნულება მნიშვნელობის მინიჭებაა. HTML „მიმტევებელია" (დახურვის ტეგი ხშირად არჩევითია), XML კი მკაცრია — ყველა ტეგი უნდა დაიხუროს.

მნიშვნელობები

მნიშვნელობა	აღწერა
`მიზანი`	HTML — ჩვენება; XML — მონაცემის აღწერა/გადატანა.
`ტეგები`	HTML — ფიქსირებული; XML — შენ იგონებ.
`მკაცრობა`	HTML — მიმტევებელი; XML — well-formed წესები სავალდებულო.
`რეგისტრი`	HTML — არ აქვს მნიშვნელობა; XML — <Note> ≠ <note>.

მაგალითები

HTML — გარეგნობა (presentation)

HTML

<h1>წიგნის სათაური</h1>
<p>ავტორი: ილია ჭავჭავაძე</p>
<p>ფასი: 15 ლარი</p>

XML — მნიშვნელობა (data)

XML

<book>
  <title>წიგნის სათაური</title>
  <author>ილია ჭავჭავაძე</author>
  <price currency="GEL">15</price>
</book>

💡 რჩევა: XHTML არის HTML, რომელიც XML-ის მკაცრ წესებს იცავს — ორი სამყაროს ხიდი.

✗ ხშირი შეცდომები

XML-ის HTML-ად აღქმა — XML ფერებსა და შრიფტებზე არაფერს „ამბობს". ვიზუალს XSLT/CSS ან აპლიკაცია აკეთებს.
ვარაუდი, რომ ბრაუზერი XML-ს „დახატავს" — ის მხოლოდ ნედლ ხეს გაჩვენებს.

XML vs JSON

XML vs. JSON (მოკლე შესავალი)

JSON (JavaScript Object Notation) დღეს ვებ-API-ების ყველაზე გავრცელებული ფორმატია. ის მსუბუქი და კომპაქტურია. ბუნებრივი კითხვაა: „თუ JSON არსებობს, რაღად XML?"

მოკლე პასუხი: ისინი სხვადასხვა ამოცანებისთვის არიან ძლიერები. JSON იდეალურია მარტივი, სწრაფი მონაცემთა გაცვლისთვის. XML ბრწყინავს იქ, სადაც საჭიროა მკაცრი ვალიდაცია, დოკუმენტური სტრუქტურა, ატრიბუტები, namespace-ები და ტრანსფორმაცია (XSLT).

ამ წიგნში ცალკე, სრული თავი ეთმობა მათ შედარებას ცხრილებით (იხ. თავი 9).

მაგალითები

XML

<user>
  <name>გიორგი</name>
  <age>25</age>
  <active>true</active>
</user>

JSON (იგივე მონაცემი)

JSON

{
  "name": "გიორგი",
  "age": 25,
  "active": true
}

💡 რჩევა: არ არსებობს „უკეთესი" — არსებობს „უფრო შესაფერისი კონკრეტული ამოცანისთვის". იხ. თავი 9.

როდის XML?

როდის გამოვიყენოთ XML და როდის — არა

XML მძლავრი ხელსაწყოა, მაგრამ არა ყველა ამოცანისთვის. გამოცდილი დეველოპერი ფორმატს ამოცანის მიხედვით ირჩევს.

მნიშვნელობები

მნიშვნელობა	აღწერა
`✅ გამოიყენე XML`	როცა გჭირდება მკაცრი ვალიდაცია (XSD); დოკუმენტური/იერარქიული მონაცემი; namespace-ები; ტრანსფორმაცია (XSLT); საწარმოო/legacy ინტეგრაცია (SOAP, ბანკები); კონფიგურაცია (Spring, Maven).
`❌ აარიდე XML`	მარტივი ვებ-API-სთვის (JSON უკეთესია); ძალიან მცირე, მსუბუქი payload-ისთვის; როცა მთავარია მინიმალური ზომა და სიჩქარე; მარტივი key-value კონფიგისთვის (.env / YAML).

💡 რჩევა: პრაქტიკული წესი: გარე API → ხშირად JSON; საწარმოო ინტეგრაცია/კონფიგი/დოკუმენტი → ხშირად XML.

✓ საუკეთესო პრაქტიკა

ფორმატი აირჩიე ამოცანით, არა მოდით — „ძველი/ახალი" არ ნიშნავს „ცუდი/კარგი".
საწარმოო ინტეგრაციაში ხშირად ფორმატი უკვე ნაკარნახევია პარტნიორის სისტემით — გაარკვიე ეს დასაწყისშივე.

შეჯამება

📋 თავის შეჯამება

XML = eXtensible Markup Language — მონაცემის აღწერის უნივერსალური, ტექსტური ფორმატი.
XML აღწერს მონაცემს, არ ამუშავებს მას; ტეგებს თავად ვიგონებთ.
შეიქმნა W3C-ის მიერ 1998 წელს, SGML-ის გამარტივების შედეგად.
ჭრის: თავსებადობის, სტრუქტურის, ვალიდაციისა და პლატფორმა-დამოუკიდებლობის პრობლემებს.
plain text/CSV — კონტექსტი არ აქვს; HTML — ჩვენებისთვისაა; JSON — მსუბუქი, მაგრამ ნაკლებად მკაცრი.
XML აირჩიე ვალიდაციის, დოკუმენტურობის, საწარმოო ინტეგრაციისა და კონფიგურაციისთვის.

💡 რჩევა: შემდეგ თავში ვისწავლით XML-ის სინტაქსის ზუსტ წესებს — ელემენტებს, ატრიბუტებს, ჩალაგებას.

სავარჯიშოები

✍️ სავარჯიშოები

აღწერე XML-ით საკუთარი თავი: სახელი, გვარი, ასაკი, ქალაქი, საყვარელი ენა. გამოიყენე ერთი root ელემენტი.
აიღე ეს CSV სტრიქონი — Lenovo,1200,8,yes — და გადააკეთე თვით-აღწერად XML-ად (ლეპტოპი: მოდელი, ფასი, RAM, მარაგშია).
ჩამოწერე 3 სიტუაცია, სადაც XML-ს აარჩევდი JSON-ის ნაცვლად, და 3 — პირიქით. დაასაბუთე.
ახსენი საკუთარი სიტყვებით, რა განსხვავებაა „მონაცემის აღწერასა" და „მონაცემის ჩვენებას" შორის.

💡 რჩევა: სავარჯიშოები წერე ტექსტურ რედაქტორში და გადაამოწმე well-formed არის თუ არა — ამას შემდეგ თავში ვისწავლით.

ქვიზი

❓ ქვიზი

უპასუხე და გადაამოწმე პასუხები (დააწკაპუნე „პასუხი").

რას ნიშნავს აბრევიატურა XML?
პასუხი
eXtensible Markup Language — გაფართოებადი მარკირების ენა.
XML პროგრამული ენაა?
პასუხი
არა. XML მონაცემს აღწერს; ის არ ითვლის და არ ასრულებს ლოგიკას.
რა მთავარი განსხვავებაა XML-სა და HTML-ს შორის?
პასუხი
HTML მონაცემის ჩვენებისთვისაა (presentation), XML — მონაცემის სტრუქტურისა და შინაარსის აღსაწერად (data). XML-ში ტეგებს თავად ვქმნით.
რომელ წელს გახდა XML W3C-ის რეკომენდაცია?
პასუხი
1998 წელს (SGML-ის გამარტივების შედეგად).
დაასახელე 2 პრობლემა, რომელსაც XML ჭრის.
პასუხი
თავსებადობა სხვადასხვა პლატფორმას შორის და მონაცემის სტრუქტურა/ვალიდაცია (ასევე თვით-აღწერადობა, პლატფორმა-დამოუკიდებლობა).

2 🔤 XML სინტაქსი

XML-ს აქვს მცირე, მაგრამ მკაცრი წესების ნაკრები. ამ თავში გავივლით ყველა მათგანს: დეკლარაცია, ელემენტები, ტეგები, ატრიბუტები, ჩალაგება (nesting), root ელემენტი, კომენტარები და სპეციალური სიმბოლოები. დოკუმენტს, რომელიც ყველა წესს იცავს, „well-formed" ეწოდება.

XML დეკლარაცია

XML დეკლარაცია (prolog)

XML ფაილი ხშირად იწყება დეკლარაციით — სპეციალური სტრიქონით, რომელიც ბრაუზერსა და parser-ს ეუბნება „ეს XML-ია, ვერსია ასეთია, კოდირება ასეთი".

დეკლარაცია არჩევითია, მაგრამ რეკომენდებულია. თუ წერ, ის უნდა იყოს ფაილის პირველივე სიმბოლო — წინ ცარიელი ხაზიც კი არ უნდა იყოს.

სინტაქსი

Syntax

<?xml version="1.0" encoding="UTF-8"?>

მნიშვნელობები

მნიშვნელობა	აღწერა
`version`	XML-ის ვერსია. პრაქტიკაში თითქმის ყოველთვის `1.0`.
`encoding`	სიმბოლოთა კოდირება. `UTF-8` — სტანდარტი (ქართულსაც სწორად ინახავს).
`standalone`	არჩევითი — `yes`/`no`; გარე DTD-ზეა დამოკიდებული თუ არა.

💡 რჩევა: შეინახე ფაილი ყოველთვის UTF-8 (BOM-ის გარეშე) კოდირებით — ეს თავიდან აგარიდებს ქართულის პრობლემებს.

✗ ხშირი შეცდომები

დეკლარაციამდე ცარიელი ხაზი ან space — იწვევს შეცდომას „XML declaration not at start of document".
დიდი ასოებით <?XML ... ?> — უნდა იყოს პატარა <?xml.
არასწორი encoding — ქართული „გადაირევა" (კრაკოზიაბრები), თუ ფაილი UTF-8 არ არის, encoding კი UTF-8 წერია.

ელემენტი / ტეგი

ელემენტები და ტეგები

ელემენტი XML-ის სამშენებლო აგური. ის შედგება გამხსნელი ტეგისგან, შინაარსისგან და დამხურავი ტეგისგან.

<title>XML საფუძვლები</title> — აქ <title> გამხსნელია, </title> დამხურავი, „XML საფუძვლები" კი შინაარსი.

ელემენტი შეიძლება იყოს ცარიელიც — მაშინ მას აქვს თვით-დამხურავი ფორმა: <br/> ან <line></line>.

სინტაქსი

Syntax

<გამხსნელი>შინაარსი</დამხურავი>
<ცარიელი/>

მნიშვნელობები

მნიშვნელობა	აღწერა
`გამხსნელი ტეგი`	`<name>` — იწყებს ელემენტს.
`დამხურავი ტეგი`	`</name>` — სვ slash-ით ამთავრებს.
`ცარიელი ელემენტი`	`<name/>` — გამხსნელი და დამხურავი ერთად.

მაგალითები

ელემენტის ნაწილები

XML

<product>
  <name>კლავიატურა</name>
  <price>49</price>
  <inStock>true</inStock>
  <discount/>
</product>

💡 რჩევა: ელემენტის სახელი დაიწყე ასოთი ან ქვედა ხაზით (_); არ დაიწყო ციფრით; არ გამოიყენო space; xml-ით დაწყება (ნებისმიერი რეგისტრით) დაცულია (reserved).

ტეგის დახურვა

დახურვის წესი — ყველა ტეგი უნდა დაიხუროს

HTML-ში ზოგ ტეგს დახურვის გარეშეც „პატიობენ" (მაგ. <br>). XML-ში ეს აკრძალულია — ყველა გამხსნელ ტეგს უნდა ჰქონდეს წყვილი დამხურავი, ან იყოს თვით-დამხურავი.

მაგალითები

❌ არასწორი (დაუხურავი)

XML

<note>
  <to>თამარი
  <message>გამარჯობა
</note>

✅ სწორი

XML

<note>
  <to>თამარი</to>
  <message>გამარჯობა</message>
</note>

✗ ხშირი შეცდომები

დამხურავი ტეგის გამოტოვება.
თვით-დამხურავ ტეგში slash-ის დავიწყება: <line>-ს ნაცვლად საჭიროა <line/>.

რეგისტრი

რეგისტრი მნიშვნელოვანია (case-sensitive)

XML-ში დიდი და პატარა ასოები განსხვავდება. <Note>, <note> და <NOTE> — სამი სხვადასხვა ელემენტია. გამხსნელი და დამხურავი ტეგი ზუსტად ერთნაირად უნდა დაიწეროს.

მაგალითები

❌ რეგისტრი არ ემთხვევა

XML

<City>თბილისი</city>

✅ ემთხვევა

XML

<city>თბილისი</city>

💡 რჩევა: აირჩიე ერთი სტილი (მაგ. camelCase ან lower-case) და დაიცავი მთელ დოკუმენტში.

ატრიბუტი

ატრიბუტები

ატრიბუტი ელემენტს დამატებით ინფორმაციას აძლევს და იწერება გამხსნელ ტეგში, სახელი="მნიშვნელობა" ფორმით.

ატრიბუტის მნიშვნელობა აუცილებლად ბრჭყალებში უნდა იყოს (ორმაგი " ან ერთმაგი '). ერთ ელემენტზე ერთი და იგივე ატრიბუტი ორჯერ ვერ გამოჩნდება.

სინტაქსი

Syntax

<element attribute="value">...</element>

მაგალითები

ატრიბუტები vs. ჩა-ელემენტები

XML

<!-- ატრიბუტებით -->
<book category="ფანტასტიკა" lang="ka">
  <title>მზის ქალაქი</title>
</book>

<!-- იგივე, ჩა-ელემენტებით -->
<book>
  <category>ფანტასტიკა</category>
  <lang>ka</lang>
  <title>მზის ქალაქი</title>
</book>

💡 რჩევა: წესი მარტივია: თუ მონაცემს შესაძლოა ქონდეს ქვე-ნაწილები ან განმეორდეს — ის ელემენტი იყოს, არა ატრიბუტი.

✓ საუკეთესო პრაქტიკა

ატრიბუტი — მეტამონაცემისთვის (id, lang, type, currency); ძირითადი მონაცემი — ჩა-ელემენტებში.
მნიშვნელობა ყოველთვის ბრჭყალებში ჩასვი.

✗ ხშირი შეცდომები

ბრჭყალების გარეშე ატრიბუტი: price=49 — არასწორია; უნდა იყოს price="49".
რთული, განმეორებადი მონაცემის ატრიბუტებში ჩატენვა — ის ჩა-ელემენტებად სჯობს.

ჩალაგება

ჩალაგება (nesting) — სწორი ჩადგმა

ელემენტები ერთმანეთში ისე უნდა ჩაიდგას, რომ არ გადაიკვეთონს. ბოლოს გახსნილი ელემენტი ჯერ უნდა დაიხუროს — ანუ „ბოლოს გახსნილი, პირველი დახურული" (როგორც ბუდე-თოჯინები).

მაგალითები

❌ გადაკვეთილი (overlapping)

XML

<b><i>ტექსტი</b></i>

✅ სწორად ჩალაგებული

XML

<b><i>ტექსტი</i></b>

რეალური იერარქია

XML

<order>
  <customer>
    <name>ნინო</name>
    <address>
      <city>ბათუმი</city>
    </address>
  </customer>
</order>

💡 რჩევა: სწორი ჩალაგება ქმნის XML-ის ხისებურ (tree) სტრუქტურას — სწორედ ამის გამოა XML ასე მძლავრი იერარქიული მონაცემისთვის.

root ელემენტი

Root (მთავარი) ელემენტი

ყველა well-formed XML დოკუმენტს უნდა ჰქონდეს ზუსტად ერთი მთავარი (root) ელემენტი, რომელიც ყველა დანარჩენს მოიცავს. ის ხის „ფესვია".

მაგალითები

❌ ორი root — შეცდომა

XML

<note>...</note>
<note>...</note>

✅ ერთი root მოიცავს ყველაფერს

XML

<notes>
  <note>...</note>
  <note>...</note>
</notes>

💡 რჩევა: root-ს ხშირად მრავლობითს არქმევენ (<books>), შიგნით კი ცალკეულ ერთეულებს — მხოლობითს (<book>).

კომენტარი

კომენტარები

კომენტარი დამხმარე ჩანაწერია ადამიანისთვის — parser მას უგულებელყოფს. წერია  შორის.

სინტაქსი

Syntax

<!-- ეს კომენტარია -->

მაგალითები

კომენტარი დოკუმენტში

XML

<config>
  <!-- მონაცემთა ბაზის პარამეტრები -->
  <db>
    <host>localhost</host>
    <!-- პორტი default-ად 3306 -->
    <port>3306</port>
  </db>
</config>

💡 რჩევა: კომენტარი არ ჩასვა ისე, თითქოს მონაცემი იყოს — parser მას არ წაიკითხავს როგორც მონაცემს.

✗ ხშირი შეცდომები

ორმაგი ტირე -- კომენტარის შიგნით — აკრძალულია.
კომენტარის ტეგის შიგნით ჩასმა — კომენტარი ვერ ჩაიდგმება სხვა ტეგში.

entity reference

სპეციალური სიმბოლოები და entity reference-ები

ზოგი სიმბოლო XML-ში „დაკავებულია" სტრუქტურისთვის. მაგ. < ყოველთვის ტეგის დასაწყისად აღიქმება. თუ მონაცემში გვინდა ასეთი სიმბოლო, ვიყენებთ entity reference-ს (ჩანაცვლებას).

ალტერნატივა — CDATA სექცია, რომელშიც ყველაფერი ნედლ ტექსტად აღიქმება.

მნიშვნელობები

მნიშვნელობა	აღწერა
`&lt;`	`<` (less than) — ნაკლები.
`&gt;`	`>` (greater than) — მეტი.
`&amp;`	`&` (ampersand) — ეს და.
`&apos;`	`'` (apostrophe) — აპოსტროფი.
`&quot;`	`"` (quotation mark) — ბრჭყალი.

მაგალითები

entity-ები მონაცემში

XML

<formula>5 &lt; 10 &amp;&amp; 10 &gt; 3</formula>
<company>Smith &amp; Co.</company>

CDATA — ნედლი ტექსტი

XML

<script>
  <![CDATA[
    if (a < b && b > c) { run(); }
  ]]>
</script>

💡 რჩევა: ხუთი entity დაიმახსოვრე: lt, gt, amp, apos, quot. დანარჩენი სიმბოლოები (ქართულის ჩათვლით) UTF-8-ში პირდაპირ იწერება.

✗ ხშირი შეცდომები

მონაცემში „შიშველი" &-ის დატოვება — ის ყოველთვის &-ად უნდა დაიწეროს.
CDATA-ს გამოყენების ფიქრი ნებისმიერი ტექსტისთვის — ის მხოლოდ მაშინ გჭირდება, როცა ბევრი სპეც-სიმბოლოა (კოდი, ფორმულა).

well-formed

Well-formed დოკუმენტი — ყველა წესი ერთად

„Well-formed" ნიშნავს XML-ს, რომელიც ყველა სინტაქსურ წესს იცავს. მხოლოდ ასეთ დოკუმენტს წაიკითხავს parser.

Well-formed ≠ valid. Well-formed = სინტაქსი სწორია. Valid = დამატებით სქემასაც (DTD/XSD) შეესაბამება (იხ. თავი 4).

მნიშვნელობები

მნიშვნელობა	აღწერა
`1`	ზუსტად ერთი root ელემენტი.
`2`	ყველა ტეგი დახურულია.
`3`	ტეგები სწორად ჩალაგებულია (არ იკვეთება).
`4`	ატრიბუტები ბრჭყალებშია.
`5`	რეგისტრი ემთხვევა გამხსნელსა და დამხურავს.
`6`	სპეც-სიმბოლოები entity-ებითაა ჩანაცვლებული.

💡 რჩევა: ბრაუზერში XML ფაილის გახსნა სწრაფი ტესტია: well-formed ხეს გაჩვენებს, შეცდომის შემთხვევაში კი — წითელ შეტყობინებას ხაზის ნომრით.

შეჯამება

📋 თავის შეჯამება

დეკლარაცია (<?xml ...?>) — ფაილის პირველი სტრიქონი, განსაზღვრავს ვერსიასა და კოდირებას.
ელემენტი = გამხსნელი + შინაარსი + დამხურავი; ცარიელი ელემენტი — თვით-დამხურავი.
ყველა ტეგი იხურება; რეგისტრი მნიშვნელოვანია; ჩალაგება არ უნდა იკვეთებოდეს.
ატრიბუტი — ბრჭყალებში, მეტამონაცემისთვის; ერთი root ელემენტი სავალდებულოა.
კომენტარი: ; სპეც-სიმბოლოები — entity-ებით (lt, gt, amp, apos, quot) ან CDATA-ით.
Well-formed = ყველა წესი დაცულია (ეს სხვაა, ვიდრე „valid").

სავარჯიშოები

✍️ სავარჯიშოები

იპოვე ამ დოკუმენტის 3 შეცდომა და გაასწორე:
<Note><to>ანა<to><msg>გმადლობ & ნახვამდის</msg></note>
დაწერე well-formed XML ერთი წიგნისთვის: სათაური, ავტორი, წელი (ატრიბუტად lang), ფასი (ატრიბუტად currency).
ტექსტში „Tom & Jerry <3" ჩაანაცვლე ყველა სპეც-სიმბოლო შესაბამისი entity-ით.
გადააკეთე ეს ატრიბუტებიანი ელემენტი ჩა-ელემენტებიან ვარიანტად: <user id="7" city="ქუთაისი"/>

ქვიზი

❓ ქვიზი

სად უნდა იდგეს XML დეკლარაცია?
პასუხი
ფაილის პირველივე სიმბოლოდ — წინ space/ცარიელი ხაზის გარეშე.
სწორია? <Price>49</price>
პასუხი
არა — რეგისტრი არ ემთხვევა. უნდა იყოს ან <Price>...</Price>, ან <price>...</price>.
რამდენი root ელემენტი შეიძლება ჰქონდეს დოკუმენტს?
პასუხი
ზუსტად ერთი.
როგორ ჩავწეროთ სიმბოლო „&" მონაცემში?
პასუხი
&
well-formed და valid ერთი და იგივეა?
პასუხი
არა. well-formed = სინტაქსი სწორია; valid = დამატებით სქემასაც (DTD/XSD) შეესაბამება.

3 🌳 მონაცემთა სტრუქტურირება

XML-ის ნამდვილი ძალა — იერარქიული (ხისებური) სტრუქტურის ბუნებრივი აღწერაა. ამ თავში ვისწავლით, როგორ მოვაწყოთ ინფორმაცია მშობელ-შვილ (parent-child) ურთიერთობებად, რეალური მაგალითებით: სტუდენტები, პროდუქტები, წიგნები და თანამშრომლები.

ორგანიზება

ინფორმაციის ორგანიზება

კარგი XML იწყება კითხვით: „რა ერთეულები (entities) მაქვს და რა ურთიერთობაა მათ შორის?"

მაგალითად, სასკოლო სისტემაში გვაქვს: სკოლა → კლასები → სტუდენტები → ნიშნები. ეს ბუნებრივი იერარქიაა, რომელიც XML-ში პირდაპირ აისახება ჩა-ელემენტებად.

კარგი სტრუქტურა: მკაფიო root, ლოგიკური დაჯგუფება, თანმიმდევრული სახელები და მინიმალური გამეორება.

💡 რჩევა: სანამ ტეგებს დაწერ, დახაზე იერარქია ფურცელზე — ეს დაგაზოგინს საათობით გადაკეთებას.

იერარქია

იერარქიული (ხისებური) სტრუქტურა

XML დოკუმენტი ფაქტობრივად ხეა (tree): root ფესვია, ელემენტები — ტოტები და ფოთლები. ყველა მონაცემს აქვს ზუსტი ადგილი ამ ხეში.

ქვემოთ — ვიზუალური ხე და მისი XML-ში გადატანა.

მაგალითები

ხის ვიზუალი (ASCII)

ხე

school
└── class (10-A)
    ├── student → name, grade
    └── student → name, grade

იგივე ხე XML-ად

XML

<school>
  <class name="10-A">
    <student>
      <name>ლუკა</name>
      <grade>9</grade>
    </student>
    <student>
      <name>მარი</name>
      <grade>10</grade>
    </student>
  </class>
</school>

💡 რჩევა: ყოველი „ჩაღრმავება" (indent) XML-ში — ხეში ერთი დონით ქვევით ჩასვლაა. სწორი indent კოდს კითხვადს ხდის.

parent / child

მშობელი და შვილი ელემენტები (parent / child)

ელემენტებს შორის ურთიერთობას ნათესაური ტერმინებით აღწერენ:

Parent (მშობელი): ელემენტი, რომელიც სხვას მოიცავს.
Child (შვილი): უშუალოდ მშობელში ჩაწერილი ელემენტი.
Sibling (და-ძმა): ერთი მშობლის შვილები.
Ancestor / Descendant: წინაპარი / შთამომავალი (რამდენიმე დონეზე).

მაგალითები

ნათესაობა მაგალითზე

XML

<library>            <!-- ancestor -->
  <book>             <!-- parent (book), child (library) -->
    <title>...</title>   <!-- child of book; sibling of author -->
    <author>...</author> <!-- sibling of title -->
  </book>
</library>

💡 რჩევა: ეს ტერმინები სასიცოცხლოდ მნიშვნელოვანია XPath-ისა და XSLT-ისთვის (თავი 7), სადაც ელემენტებს სწორედ ნათესაობით მივმართავთ.

სტუდენტები

რეალური მაგალითი: სტუდენტები

სტუდენტთა სია — კლასიკური „ერთი მშობელი, ბევრი ერთგვაროვანი შვილი" სტრუქტურა. შენიშნე, როგორ მეორდება <student> ელემენტი.

მაგალითები

students.xml

XML

<?xml version="1.0" encoding="UTF-8"?>
<students>
  <student id="101">
    <firstName>ნინო</firstName>
    <lastName>ბერიძე</lastName>
    <faculty>ინფორმატიკა</faculty>
    <gpa>3.8</gpa>
  </student>
  <student id="102">
    <firstName>დათო</firstName>
    <lastName>გელაშვილი</lastName>
    <faculty>ეკონომიკა</faculty>
    <gpa>3.4</gpa>
  </student>
</students>

💡 რჩევა: უნიკალური ჩამნაცვლებელი (id) ატრიბუტად ჩაწერე — ეს გაცვლისა და ვალიდაციისას გამოგადგება.

პროდუქტები

რეალური მაგალითი: პროდუქტები (მაღაზია)

ონლაინ-მაღაზიის კატალოგი: კატეგორიები მოიცავენ პროდუქტებს, პროდუქტს კი — ფასი, მარაგი, მახასიათებლები.

მაგალითები

catalog.xml

XML

<catalog>
  <category name="ელექტრონიკა">
    <product sku="LP-15">
      <name>ლეპტოპი Pro 15</name>
      <price currency="GEL">2999</price>
      <inStock>true</inStock>
      <specs>
        <ram unit="GB">16</ram>
        <storage unit="GB">512</storage>
      </specs>
    </product>
  </category>
</catalog>

🌍 რეალური გამოყენება

სწორედ ასე გამოიყურება პროდუქტის feed-ი, რომელსაც მაღაზიები აგზავნიან Google Shopping-ში, ფასების აგრეგატორებსა და მარკეტფლეისებში — XML feed დღემდე გავრცელებული სტანდარტია.

წიგნები

რეალური მაგალითი: წიგნები (ბიბლიოთეკა)

ბიბლიოთეკის კატალოგი — XML-ის ერთ-ერთი ისტორიული „სამშობლო" (დოკუმენტების აღწერა). ერთ წიგნს შეიძლება ჰყავდეს რამდენიმე ავტორი.

მაგალითები

library.xml

XML

<library name="ეროვნული ბიბლიოთეკა">
  <book isbn="978-9941-0-1234-5">
    <title>ვეფხისტყაოსანი</title>
    <authors>
      <author>შოთა რუსთაველი</author>
    </authors>
    <year>1180</year>
    <genre>ეპოსი</genre>
  </book>
</library>

💡 რჩევა: როცა ერთეულს შეიძლება ჰყავდეს „ბევრი რამე" (ბევრი ავტორი), შექმნი შემფუთველი ელემენტი (<authors>) და მასში ჩადგე განმეორებადი <author>.

თანამშრომლები

რეალური მაგალითი: თანამშრომლები (HR)

კომპანიის ორგანიზაციული სტრუქტურა: დეპარტამენტები → თანამშრომლები → კონტაქტი/ხელფასი. ღრმა იერარქიის კარგი მაგალითია.

მაგალითები

company.xml

XML

<company name="TechCorp">
  <department name="Engineering">
    <employee id="E-001">
      <name>ანა ხ.</name>
      <position>Backend დეველოპერი</position>
      <salary currency="USD">3500</salary>
      <contact>
        <email>ana@techcorp.ge</email>
        <phone>+995 555 12 34 56</phone>
      </contact>
    </employee>
  </department>
</company>

🌍 რეალური გამოყენება

ასეთი სტრუქტურა HR და ERP სისტემებში გამოიყენება თანამშრომელთა მონაცემების ერთი სისტემიდან მეორეში გადასატანად (მაგ. SAP-დან სახელფასო პროგრამაში).

შეჯამება

📋 თავის შეჯამება

XML დოკუმენტი ხეა: root → ტოტები → ფოთლები.
ურთიერთობები: parent, child, sibling, ancestor/descendant.
განმეორებადი ერთეულები ერთ შემფუთველ ელემენტში ჯგუფდება (<students> → ბევრი <student>).
უნიკალური id-ები ატრიბუტებად ეხმარება იდენტიფიკაციასა და გაცვლას.
ერთი და იგივე იდეა მუშაობს ნებისმიერ დომენში: სტუდენტები, პროდუქტები, წიგნები, თანამშრომლები.

სავარჯიშოები

✍️ სავარჯიშოები

დააპროექტე XML სტრუქტურა რესტორნის მენიუსთვის: კატეგორიები (სალათები, ცხელი კერძები...) → კერძები → დასახელება, ფასი, შემადგენლობა.
აღწერე 3 სტუდენტი, თითოეულს — რამდენიმე საგანი და ნიშანი (გამოიყენე შემფუთველი ელემენტი).
დახაზე ხის დიაგრამა შენი ფაკულტეტის სტრუქტურისთვის და გადაიყვანე XML-ად.
ერთი და იგივე მონაცემი (მანქანა: მარკა, მოდელი, წელი) ჩაწერე ჯერ ატრიბუტებით, მერე ჩა-ელემენტებით. რომელი უფრო კითხვადია და რატომ?

ქვიზი

❓ ქვიზი

XML-ის სტრუქტურას რა მონაცემთა ტიპს ადარებენ ხშირად?
პასუხი
ხეს (tree) — root, ტოტები, ფოთლები.
როგორ ეწოდება ერთი მშობლის შვილ ელემენტებს?
პასუხი
siblings (და-ძმა ელემენტები).
როგორ ჯობს 5 სტუდენტის წარმოდგენა?
პასუხი
ერთი შემფუთველი <students> და მასში 5 განმეორებადი <student>.
რა უპირატესობას იძლევა id ატრიბუტი თითო ერთეულზე?
პასუხი
უნიკალურ იდენტიფიკაციას — ეხმარება გაცვლას, ძებნასა და ვალიდაციას.

4 ✅ XML ვალიდაცია

Well-formed საკმარისი არ არის — ხშირად გვინდა ვაიძულოთ დოკუმენტი, დაიცვას კონკრეტული წესები: რომელი ელემენტებია სავალდებულო, რა თანმიმდევრობით, რა ტიპის მონაცემი. ამას აკეთებენ სქემები — DTD და XML Schema (XSD).

რატომ ვალიდაცია?

რატომ არსებობს ვალიდაცია

წარმოიდგინე ბანკი იღებს გადახდის XML-ს სხვა სისტემიდან. რა მოხდება, თუ <amount> ელემენტი საერთოდ აკლია? ან თანხის ნაცვლად ტექსტი „ას ლარი" წერია? კატასტროფა.

ვალიდაცია არის მონაცემის „კონტრაქტი": „მე გავცემ/მივიღებ მხოლოდ ისეთ XML-ს, რომელიც ამ ზუსტ წესებს ემორჩილება." ეს კი მანამდე მოწმდება, სანამ მონაცემი დამუშავდება.

Well-formed = სინტაქსი სწორია. Valid = სქემასაც შეესაბამება (სტრუქტურა + ტიპები).

💡 რჩევა: ვალიდაცია ბაგებს იჭერს საზღვარზე (input-ის შემოსვლისას), არა ღრმად პროგრამის შიგნით — ეს ბევრად იაფი და უსაფრთხოა.

DTD

DTD საფუძვლები (Document Type Definition)

DTD ვალიდაციის ყველაზე ძველი მექანიზმია. ის აღწერს, რომელი ელემენტები არსებობს, რა შვილები ჰყავთ და რა ატრიბუტები.

DTD მარტივი და კომპაქტურია, მაგრამ აქვს მნიშვნელოვანი ნაკლი: არ იცის მონაცემთა ტიპები (ვერ იტყვის „ეს რიცხვი უნდა იყოს") და თავად XML-ის სინტაქსით არ იწერება.

სინტაქსი

Syntax

<!ELEMENT note (to, from, heading, body)>
<!ELEMENT to (#PCDATA)>

მნიშვნელობები

მნიშვნელობა	აღწერა
`#PCDATA`	Parsed Character Data — ტექსტური შინაარსი.
`+`	ერთი ან მეტი (one or more).
`*`	ნული ან მეტი (zero or more).
`?`	არჩევითი (zero or one).

მაგალითები

note.dtd

DTD

<!ELEMENT note (to, from, heading, body)>
<!ELEMENT to      (#PCDATA)>
<!ELEMENT from    (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body    (#PCDATA)>

DTD-ს მიბმა XML-ში

XML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE note SYSTEM "note.dtd">
<note>
  <to>თამარი</to>
  <from>გიორგი</from>
  <heading>შეხსენება</heading>
  <body>შეხვედრა ხუთშაბათს</body>
</note>

💡 რჩევა: ახალ პროექტებში DTD-ს ნაცვლად XSD სჯობს. DTD ძირითადად legacy სისტემებსა და დოკუმენტურ ფორმატებში შეგხვდება.

✗ ხშირი შეცდომები

DTD-სგან მონაცემთა ტიპის მოლოდინი — ის ვერ ამოწმებს რიცხვი/თარიღი სწორია თუ არა.
namespace-ების DTD-ში გამოყენების მცდელობა — DTD მათ კარგად ვერ უჭერს მხარს.

XSD W3C XML Schema

XML Schema (XSD)

XSD (XML Schema Definition) ვალიდაციის თანამედროვე, მძლავრი მექანიზმია. მისი ორი დიდი უპირატესობა DTD-სთან შედარებით:

მონაცემთა ტიპები: string, integer, decimal, date, boolean და ა.შ. — შეგვიძლია მოვითხოვოთ „აქ რიცხვი იყოს", „აქ თარიღი".
თავად XML-ია: XSD იწერება XML-ის სინტაქსით, ანუ იგივე ხელსაწყოები ამუშავებს.

დამატებით XSD უჭერს მხარს namespace-ებს, შეზღუდვებს (მინ/მაქს, რეგექსი), default მნიშვნელობებს და ხელახლა გამოყენებად ტიპებს.

მნიშვნელობები

მნიშვნელობა	აღწერა
`xs:string`	ტექსტი.
`xs:integer`	მთელი რიცხვი.
`xs:decimal`	ათწილადი (ფასი, თანხა).
`xs:date`	თარიღი (YYYY-MM-DD).
`xs:boolean`	true / false.

მაგალითები

note.xsd

XML

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="note">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="to"      type="xs:string"/>
        <xs:element name="from"    type="xs:string"/>
        <xs:element name="heading" type="xs:string"/>
        <xs:element name="body"    type="xs:string"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

ტიპები და შეზღუდვები (constraints)

XML

<xs:element name="age">
  <xs:simpleType>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0"/>
      <xs:maxInclusive value="120"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

💡 რჩევა: XSD-ით შეგიძლია მოითხოვო: „email უნდა ემთხვეოდეს ამ რეგულარულ გამოსახულებას" — ანუ ვალიდაცია ფორმატსაც ამოწმებს, არა მხოლოდ ტიპს.

✓ საუკეთესო პრაქტიკა

ახალ პროექტებში ვალიდაციისთვის XSD აირჩიე — ტიპები კრიტიკულია.
ხშირად გამოყენებად ტიპებს (მისამართი, თანხა) ცალკე complexType-ად აღწერე და ხელახლა გამოიყენე.

სარგებელი

ვალიდაციის სარგებელი

რატომ ღირს სქემის წერის დამატებითი შრომა? იმიტომ, რომ ის თავიდან გვაცილებს ბევრად ძვირ პრობლემებს.

მნიშვნელობები

მნიშვნელობა	აღწერა
`უსაფრთხოება`	არასწორი/მავნე მონაცემი იჭრება შემოსვლისთანავე, პროგრამაში შესვლამდე.
`საიმედოობა`	ორი სისტემა ერთ „კონტრაქტს" იცავს — ნაკლები ბაგი ინტეგრაციაში.
`დოკუმენტაცია`	სქემა თავად არის ფორმატის ცოცხალი, ზუსტი დოკუმენტი.
`ავტომატიზაცია`	კოდი/ფორმები შეიძლება პირდაპირ სქემიდან დაგენერირდეს.
`თავსებადობა`	პარტნიორი წინასწარ ხედავს, რა ფორმატი მოგვწონს.

🌍 რეალური გამოყენება

SOAP ვებ-სერვისები (ბანკები, სახელმწიფო სისტემები) ყოველთვის ეფუძნება XSD-ს — WSDL-ის შიგნით სწორედ XSD აღწერს შეტყობინებების ფორმატს. ამიტომ XSD-ის გაგება საწარმოო ინტეგრაციისთვის სავალდებულოა.

შეჯამება

📋 თავის შეჯამება

Valid = well-formed + სქემას (DTD/XSD) შეესაბამება.
DTD — ძველი, მარტივი; ტიპები არ იცის; არ არის XML.
XSD — თანამედროვე, მძლავრი; მონაცემთა ტიპები, შეზღუდვები, namespace-ები; თავად XML-ია.
სარგებელი: უსაფრთხოება, საიმედოობა, დოკუმენტაცია, ავტომატიზაცია, თავსებადობა.
საწარმოო ინტეგრაცია (SOAP) XSD-ს ეფუძნება.

სავარჯიშოები

✍️ სავარჯიშოები

დაწერე XSD <product>-ისთვის: name (string, სავალდებულო), price (decimal, ≥ 0), inStock (boolean).
ახსენი, რატომ ვერ დაიჭერს DTD შეცდომას <age>ოცი</age>, XSD კი — დაიჭერს.
ჩამოწერე 3 პრობლემა, რომელსაც ვალიდაცია თავიდან აგაცილებს ბანკის გადახდის სისტემაში.
XSD-ში დაამატე შეზღუდვა email ველზე, რომ მან რეგულარულ გამოსახულებას მიჰყვეს.

ქვიზი

❓ ქვიზი

DTD-სა და XSD-ს შორის მთავარი განსხვავება?
პასუხი
XSD იცნობს მონაცემთა ტიპებს (string/integer/date...) და თავად XML-ია; DTD — არც ერთს.
valid დოკუმენტი ყოველთვის well-formed-იცაა?
პასუხი
დიახ — ვალიდურობა well-formed-ობას გულისხმობს, პლუს სქემასთან შესაბამისობას.
SOAP ვებ-სერვისები რომელ სქემას ეფუძნება?
პასუხი
XSD-ს (WSDL-ის შიგნით).
დაასახელე ვალიდაციის 2 სარგებელი.
პასუხი
უსაფრთხოება (ცუდი input იჭრება) და დოკუმენტაცია/საიმედოობა (ერთი კონტრაქტი ორ სისტემას შორის).

5 ⚙️ XML კონფიგურაციაში

XML წლების განმავლობაში იყო პროგრამული უზრუნველყოფის კონფიგურაციის სტანდარტი. Java-ს სამყარო (web.xml, Spring, Maven) და .NET თითქმის მთლიანად XML-ზე იყო აგებული. ამ თავში ვნახავთ რეალურ კონფიგურაციებს და გავიგებთ, რატომ გახდა XML ასე პოპულარული ამ მიზნით.

რატომ XML კონფიგი?

რატომ გახდა XML პოპულარული კონფიგურაციისთვის

პროგრამას სჭირდება პარამეტრები: მონაცემთა ბაზის მისამართი, პორტი, გზები, კომპონენტების სია. ეს პარამეტრები კოდში „ჩაკერვა" ცუდია — ყოველი ცვლილება ხელახალ კომპილაციას მოითხოვს. სჯობს ისინი ცალკე ფაილში გავიტანოთ.

XML იდეალური აღმოჩნდა ამისთვის, რადგან ის:

იერარქიულია — კონფიგურაცია ბუნებრივად დაჯგუფებულია (სერვერი → კავშირები → თითო კავშირი).
თვით-აღწერადია — ტეგების სახელები ხსნის, რას აკონფიგურირებ.
ვალიდირებადია — XSD-ით პროგრამა ამოწმებს, კონფიგი სწორია თუ არა გაშვებამდე.
კომენტარების მხარდამჭერია — შეგიძლია ახსნა ჩაამატო პირდაპირ ფაილში.

დღეს ბევრი პროექტი YAML-ს ან .properties-ს იყენებს, მაგრამ უამრავი მოქმედი (და ახალი) საწარმოო სისტემა კვლავ XML-ზე დგას.

💡 რჩევა: კონფიგურაცია კოდისგან გამოყოფა — პროფესიული პრაქტიკის საფუძველია. XML იყო ერთ-ერთი პირველი ფართოდ მიღებული გზა ამის გასაკეთებლად.

web.xml

ვებ-აპლიკაცია: web.xml (Java EE)

Java-ს ვებ-აპლიკაციებში web.xml (deployment descriptor) აღწერდა, როგორ უნდა გაშვებულიყო აპლიკაცია სერვერზე: რომელი servlet-ი რომელ მისამართს ემსახურება, რა საწყისი გვერდია, რა ფილტრები მუშაობს.

მაგალითები

web.xml — servlet-ის mapping

XML

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="3.0">
  <servlet>
    <servlet-name>mainServlet</servlet-name>
    <servlet-class>ge.mfes.MainServlet</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>mainServlet</servlet-name>
    <url-pattern>/app/*</url-pattern>
  </servlet-mapping>
  <welcome-file-list>
    <welcome-file>index.html</welcome-file>
  </welcome-file-list>
</web-app>

🌍 რეალური გამოყენება

ათასობით კორპორაციული Java-აპლიკაცია დღემდე მუშაობს web.xml-ით. ანოტაციებმა (annotations) ის ნაწილობრივ ჩაანაცვლა, მაგრამ legacy სისტემებში ის სტანდარტად რჩება.

Spring XML

Java: Spring Framework კონფიგურაცია

Spring — Java-ს ერთ-ერთი ყველაზე გავრცელებული ფრეიმვორკი. წლების განმავლობაში მისი ცენტრალური იდეა (Dependency Injection) კონფიგურირდებოდა XML ფაილით: სად რომელი ობიექტი (bean) იქმნება და როგორ უკავშირდება სხვებს.

მაგალითები

applicationContext.xml

XML

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans">
  <bean id="userService" class="ge.mfes.UserService">
    <property name="repository" ref="userRepository"/>
  </bean>
  <bean id="userRepository" class="ge.mfes.UserRepository">
    <property name="dataSource" ref="mainDataSource"/>
  </bean>
</beans>

💡 რჩევა: შენიშნე ref="userRepository" — ერთი bean მიუთითებს მეორეზე. XML-ის იერარქია და ატრიბუტები იდეალურად ერგება ასეთ კავშირებს.

🌍 რეალური გამოყენება

თანამედროვე Spring Boot ანოტაციებსა და Java-კონფიგს ამჯობინებს, მაგრამ XML-კონფიგი დღემდე სრულად მხარდაჭერილია და უამრავ საწარმოო პროექტშია გამოყენებული.

pom.xml

Java: Maven pom.xml

Maven Java-პროექტების აგების (build) ხელსაწყოა. მისი ცენტრალური ფაილი — pom.xml (Project Object Model) — XML-ში აღწერს: პროექტის სახელს, ვერსიას და, რაც მთავარია, დამოკიდებულებებს (dependencies) — რომელ ბიბლიოთეკებს იყენებს პროექტი.

მაგალითები

pom.xml — dependencies

XML

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>ge.mfes</groupId>
  <artifactId>edu-app</artifactId>
  <version>1.0.0</version>
  <dependencies>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-core</artifactId>
      <version>6.1.0</version>
    </dependency>
  </dependencies>
</project>

💡 რჩევა: მთელი Java-ს ეკოსისტემა (Maven Central) მილიონობით ბიბლიოთეკას pom.xml-ის მეტამონაცემებით მართავს — XML აქ დე-ფაქტო სტანდარტია.

🌍 რეალური გამოყენება

ყოველ დღე მსოფლიოში მილიონობით build სრულდება Maven-ით — და თითოეული კითხულობს pom.xml-ს. ეს XML-ის ცოცხალი, მასშტაბური გამოყენების ნათელი მაგალითია.

.NET config

.NET კონფიგურაცია (app.config / web.config)

Microsoft-ის .NET პლატფორმაზე აპლიკაციის პარამეტრები ტრადიციულად ინახებოდა app.config ან web.config ფაილებში — სუფთა XML-ში. იქ ეწერა მონაცემთა ბაზის connection string-ები, აპლიკაციის პარამეტრები და სხვა.

მაგალითები

web.config

XML

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <connectionStrings>
    <add name="MainDb"
         connectionString="Server=localhost;Database=edu;" />
  </connectionStrings>
  <appSettings>
    <add key="PageSize" value="20" />
    <add key="EnableCache" value="true" />
  </appSettings>
</configuration>

💡 რჩევა: შენიშნე ნიმუში: ყველა პლატფორმამ (Java, .NET) ერთსა და იმავე იდეას მიაგნო — კონფიგი XML-ში. ეს XML-ის უნივერსალურობის მტკიცებულებაა.

🌍 რეალური გამოყენება

კლასიკური ASP.NET აპლიკაციები დღემდე web.config-ით კონფიგურირდება. ახალ .NET-ში მას JSON (appsettings.json) ენაცვლება, მაგრამ მილიონობით მოქმედი სისტემა კვლავ XML-კონფიგზე დგას.

შეჯამება

📋 თავის შეჯამება

კონფიგურაცია კოდისგან ცალკე ფაილში გამოაქვთ — XML ამისთვის იდეალური აღმოჩნდა.
XML-ის ძალა კონფიგში: იერარქია, თვით-აღწერადობა, ვალიდაცია (XSD), კომენტარები.
Java: web.xml (servlet-ები), Spring (bean-ები), Maven (pom.xml — dependencies).
.NET: app.config / web.config (connection string-ები, appSettings).
თანამედროვე პროექტებში YAML/JSON ხშირია, მაგრამ XML-კონფიგი მასობრივად კვლავ ცოცხალია.

ქვიზი

❓ ქვიზი

რატომ არ ვწეროთ პარამეტრები პირდაპირ კოდში?
პასუხი
ყოველი ცვლილება ხელახალ კომპილაციას/დეპლოის მოითხოვს; ცალკე ფაილი უფრო მოქნილია და უსაფრთხო.
რას მართავს Maven-ის pom.xml?
პასუხი
პროექტის მეტამონაცემებსა და დამოკიდებულებებს (dependencies) — რომელ ბიბლიოთეკებს იყენებს პროექტი.
დაასახელე XML-ის ერთი თვისება, რომელიც მას კონფიგისთვის კარგს ხდის.
პასუხი
იერარქიულობა (ან თვით-აღწერადობა / ვალიდაცია / კომენტარების მხარდაჭერა).

6 🔄 მონაცემთა გაცვლა

XML-ის ერთ-ერთი უმთავრესი დანიშნულება — სხვადასხვა სისტემას შორის მონაცემის გადაცემაა. ამ თავში ვნახავთ, როგორ ცვლიან XML-ით ინფორმაციას სისტემები, API-ები და მსხვილი საწარმოო პროგრამები: საბანკო, CRM და ERP სისტემები.

ინტეგრაცია

სისტემების ინტეგრაცია — საერთო ენა

დიდ კომპანიაში ერთდროულად მუშაობს ათეულობით პროგრამა: სასაწყობო, ბუღალტერია, ონლაინ-მაღაზია, მიტანის სერვისი. ისინი ერთმანეთს უნდა „ესაუბრონ" — როცა შეკვეთა შემოდის, ეს ინფორმაცია ყველა სისტემამდე უნდა მივიდეს.

პრობლემა: სისტემები სხვადასხვა ენაზეა დაწერილი, სხვადასხვა ბაზას იყენებს. XML არის ნეიტრალური „საერთო ენა", რომელსაც ყველა მათგანი კითხულობს და წერს. ერთი სისტემა აგენერირებს XML-ს, მეორე კითხულობს — შიდა განსხვავებებს მნიშვნელობა აღარ აქვს.

💡 რჩევა: ამ მიდგომას „loose coupling" ეწოდება — სისტემები დაკავშირებულია, მაგრამ ერთმანეთის შიდა აგებულებაზე დამოკიდებული არ არის. XML ამის კლასიკური ხელსაწყოა.

API / ვებ-სერვისი

API-ები და ვებ-სერვისები

API (Application Programming Interface) არის „კარი", რომლითაც ერთი პროგრამა მეორეს მონაცემს სთხოვს ან აწვდის. ბევრი API (განსაკუთრებით საწარმოო და სახელმწიფო) მონაცემს XML-ის სახით ცვლის.

ტიპური სცენარი: კლიენტი აგზავნის XML-მოთხოვნას, სერვერი აბრუნებს XML-პასუხს. ფორმატი წინასწარ შეთანხმებული და (ხშირად) XSD-ით ვალიდირებულია.

მაგალითები

XML-მოთხოვნა (request)

XML

<getWeatherRequest>
  <city>თბილისი</city>
  <date>2026-06-01</date>
</getWeatherRequest>

XML-პასუხი (response)

XML

<getWeatherResponse>
  <city>თბილისი</city>
  <temperature unit="C">27</temperature>
  <condition>მზიანი</condition>
</getWeatherResponse>

💡 რჩევა: REST API-ები ხშირად JSON-ს იყენებენ, მაგრამ SOAP ვებ-სერვისები (იხ. თავი 8) ყოველთვის XML-ზე მუშაობენ.

შეტყობინება

შეტყობინების გაცვლის პრაქტიკული მაგალითი

ვნახოთ რეალური შეკვეთის შეტყობინება, რომელსაც ონლაინ-მაღაზია უგზავნის სასაწყობო სისტემას. ერთ დოკუმენტში ეტევა მთელი საჭირო ინფორმაცია: მყიდველი, ნივთები, მისამართი.

მაგალითები

order-message.xml

XML

<?xml version="1.0" encoding="UTF-8"?>
<order id="ORD-2026-5571" date="2026-05-30">
  <customer>
    <name>ნინო კაპანაძე</name>
    <email>nino@example.ge</email>
  </customer>
  <items>
    <item sku="LP-15" qty="1">
      <name>ლეპტოპი Pro 15</name>
      <price currency="GEL">2999</price>
    </item>
    <item sku="MS-02" qty="2">
      <name>მაუსი</name>
      <price currency="GEL">45</price>
    </item>
  </items>
  <shipping>
    <city>თბილისი</city>
    <address>ვაჟა-ფშაველას 12</address>
  </shipping>
</order>

💡 რჩევა: ერთი თვით-აღწერადი დოკუმენტი ატარებს მთელ კონტექსტს — მიმღებ სისტემას დამატებითი ახსნა არ სჭირდება. სწორედ ეს არის XML-ის ძალა გაცვლაში.

საბანკო / CRM / ERP

საწარმოო სისტემები: ბანკები, CRM, ERP

დიდ ბიზნეს-სისტემებში XML მონაცემთა გაცვლის ხერხემალია:

საბანკო სისტემები: გადარიცხვები საერთაშორისო სტანდარტით ISO 20022 (XML-ფორმატი) იგზავნება ბანკებს შორის. ფინანსურ სამყაროში XML ფაქტობრივი კანონია.
CRM (Customer Relationship Management): კლიენტების მონაცემები (Salesforce და სხვა) ხშირად XML-ით სინქრონიზდება გარე სისტემებთან.
ERP (Enterprise Resource Planning): SAP და მსგავსი სისტემები XML-ით ცვლიან მონაცემს მოდულებსა და გარე პარტნიორებს შორის (IDoc და სხვა ფორმატები).

მაგალითები

საბანკო გადარიცხვა (გამარტივებული ISO 20022 სტილი)

XML

<payment>
  <debtor account="GE29NB0000000101904917">ი. გელაშვილი</debtor>
  <creditor account="GE60NB0000000123456789">შპს "ვაჭრობა"</creditor>
  <amount currency="GEL">1500.00</amount>
  <purpose>ინვოისი #4471-ის გადახდა</purpose>
</payment>

🌍 რეალური გამოყენება

ფინანსურ სექტორში მონაცემის ფორმატს ნდობა და სიზუსტე სჭირდება. XML-ის მკაცრი ვალიდაცია (XSD) და თვით-აღწერადობა მას საბანკო გაცვლისთვის იდეალურს ხდის — სწორედ ამიტომ ISO 20022 XML-ზეა აგებული.

შეჯამება

📋 თავის შეჯამება

XML არის სისტემებს შორის ნეიტრალური „საერთო ენა" (loose coupling).
API-ები და ვებ-სერვისები ცვლიან XML-მოთხოვნებსა და XML-პასუხებს.
ერთი თვით-აღწერადი შეტყობინება ატარებს მთელ კონტექსტს.
საბანკო (ISO 20022), CRM და ERP (SAP) სისტემები მასობრივად ეყრდნობიან XML-ს.
სიზუსტე და ვალიდაცია XML-ს ფინანსური გაცვლისთვის შეუცვლელად აქცევს.

სავარჯიშოები

✍️ სავარჯიშოები

დააპროექტე XML-შეტყობინება, რომელსაც კაფე უგზავნის მიტანის სერვისს: შეკვეთის ნომერი, კერძები, მისამართი, ფასი.
დაწერე XML-მოთხოვნა და XML-პასუხი „ვალუტის კურსის" API-სთვის.
ახსენი საკუთარი სიტყვებით, რა არის „loose coupling" და რატომ ეხმარება მას XML.
რატომ ეყრდნობა საბანკო სექტორი XML-ს JSON-ის ნაცვლად? დაასახელე 2 მიზეზი.

ქვიზი

❓ ქვიზი

რას ნიშნავს, რომ XML „ნეიტრალური" ფორმატია?
პასუხი
ის არ არის მიბმული კონკრეტულ ენაზე ან OS-ზე — ნებისმიერი სისტემა კითხულობს და წერს მას.
რომელი საერთაშორისო საბანკო სტანდარტი ეფუძნება XML-ს?
პასუხი
ISO 20022.
რას ნიშნავს აბრევიატურები CRM და ERP?
პასუხი
CRM — Customer Relationship Management; ERP — Enterprise Resource Planning.

7 🔀 XML ტრანსფორმაციები

ხშირად ერთი XML უნდა გადავაკეთოთ სხვა ფორმაში: ვებ-გვერდად (HTML), სხვა XML-ად, ან ტექსტურ ანგარიშად. ამას აკეთებს XSLT — XML-ის ტრანსფორმაციის სპეციალური ენა. ეს თავი ხსნის, როგორ მუშაობს და სად გამოიყენება ბიზნესში.

XSLT W3C

რა არის XSLT

XSLT (eXtensible Stylesheet Language Transformations) არის ენა, რომელიც XML-ს გადააქცევს სხვა დოკუმენტად. შენ წერ „წესების ფურცელს" (stylesheet), რომელიც ამბობს: „როცა ნახავ ამ ელემენტს, გამოიტანე აი ეს".

მნიშვნელოვანი იდეა: XSLT თავად XML-ია, და ის არ ცვლის საწყის ფაილს — ის ქმნის ახალს. ერთი წყაროდან შეგვიძლია მრავალი სხვადასხვა შედეგი მივიღოთ.

ელემენტებამდე მისასვლელად XSLT იყენებს XPath-ს — „მისამართების" ენას XML-ხეში (მაგ. /catalog/product/name).

💡 რჩევა: წარმოიდგინე XSLT როგორც „რეცეპტი": საწყისი XML — პროდუქტები, XSLT — რეცეპტი, შედეგი — მზა კერძი (HTML გვერდი, PDF-ის წყარო, სხვა XML).

XML → HTML

XML-დან HTML-ში

ყველაზე გავრცელებული ტრანსფორმაცია — მონაცემიდან ვებ-გვერდის გენერაცია. გვაქვს XML მონაცემი (პროდუქტები), XSLT კი მისგან ლამაზ HTML ცხრილს ქმნის.

მაგალითები

1. საწყისი მონაცემი (catalog.xml)

XML

<catalog>
  <product><name>კლავიატურა</name><price>49</price></product>
  <product><name>მაუსი</name><price>45</price></product>
</catalog>

2. ტრანსფორმაცია (style.xsl)

XML

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <html><body>
      <h2>პროდუქტები</h2>
      <table border="1">
        <tr><th>დასახელება</th><th>ფასი</th></tr>
        <xsl:for-each select="catalog/product">
          <tr>
            <td><xsl:value-of select="name"/></td>
            <td><xsl:value-of select="price"/> ₾</td>
          </tr>
        </xsl:for-each>
      </table>
    </body></html>
  </xsl:template>
</xsl:stylesheet>

3. შედეგი (HTML)

HTML

<html><body>
  <h2>პროდუქტები</h2>
  <table border="1">
    <tr><th>დასახელება</th><th>ფასი</th></tr>
    <tr><td>კლავიატურა</td><td>49 ₾</td></tr>
    <tr><td>მაუსი</td><td>45 ₾</td></tr>
  </table>
</body></html>

💡 რჩევა: <xsl:for-each> გადის ყველა ელემენტზე ციკლურად, <xsl:value-of> კი იღებს მნიშვნელობას. ეს XSLT-ის ორი ყველაზე ხშირი ბრძანებაა.

XML → სხვა

XML სხვა ფორმატებში

XSLT-ით XML შეიძლება გადავიყვანოთ თითქმის ნებისმიერ ტექსტურ ფორმატში:

XML → HTML — ვებ-ჩვენება.
XML → XML — ერთი სქემიდან მეორეში (ხშირი ინტეგრაციაში, როცა ორი სისტემის ფორმატი არ ემთხვევა).
XML → ტექსტი / CSV — ანგარიშები, ექსპორტი.
XML → XSL-FO → PDF — ბეჭდვადი დოკუმენტები (ინვოისები, კონტრაქტები).

💡 რჩევა: XSLT განსაკუთრებით ძლიერია „ფორმატიდან ფორმატში" თარგმნისას — ეს მისი დანიშნულების გული-გულია.

🌍 რეალური გამოყენება

კლასიკური ბიზნეს-შემთხვევა: პარტნიორი გიგზავნის შეკვეთებს თავისი XML-ფორმატით, შენი სისტემა კი სხვა ფორმატს ელოდება. XSLT-ის ერთი ფაილი თარგმნის ერთს მეორედ — კოდის წერის გარეშე. ეს უამრავ საინტეგრაციო პლატფორმაში გამოიყენება.

ბიზნეს-ქეისები

პრაქტიკული ბიზნეს-გამოყენება

სად ხედავ XSLT-ს რეალურ სამყაროში:

ინვოისები: ერთი XML-მონაცემი → ლამაზი PDF მომხმარებლისთვის + მკაცრი XML საგადასახადო სამსახურისთვის.
ანგარიშგება: საწყობის XML → მენეჯერის HTML-დაშბორდი.
პუბლიკაცია: ერთი დოკუმენტი → ვებ-ვერსია, ბეჭდვითი ვერსია და მობილური ვერსია, სამივე ერთი წყაროდან.
B2B ინტეგრაცია: პარტნიორების სხვადასხვა XML-ფორმატის შენს შიდა ფორმატთან „გათარგმნა".

💡 რჩევა: ერთი წყარო — მრავალი შედეგი. ეს „single source of truth" პრინციპია: მონაცემი ერთ ადგილას ინახება, ჩვენების ფორმები კი XSLT-ით გენერირდება.

შეჯამება

📋 თავის შეჯამება

XSLT გარდაქმნის XML-ს სხვა დოკუმენტად; თავად XML-ია და საწყისს არ ცვლის.
ელემენტებამდე მისასვლელად იყენებს XPath-ს.
მთავარი ბრძანებები: <xsl:template>, <xsl:for-each>, <xsl:value-of>.
გამოსავალი: HTML, სხვა XML, ტექსტი/CSV, PDF (XSL-FO).
ბიზნესში: ინვოისები, ანგარიშგება, პუბლიკაცია, B2B ფორმატების თარგმნა (single source of truth).

ქვიზი

❓ ქვიზი

რას აკეთებს XSLT?
პასუხი
გარდაქმნის (transforms) XML-ს სხვა ფორმატად — HTML, სხვა XML, ტექსტი და ა.შ.
XSLT ცვლის საწყის XML ფაილს?
პასუხი
არა — ის ქმნის ახალ შედეგს, წყარო უცვლელი რჩება.
რა ენით მიდის XSLT ელემენტებამდე XML-ხეში?
პასუხი
XPath-ით.
დაასახელე ერთი ბიზნეს-შემთხვევა XSLT-ისთვის.
პასუხი
მაგ. ერთი მონაცემიდან ინვოისის PDF + საგადასახადო XML; ან პარტნიორის ფორმატის თარგმნა შიდა ფორმატში.

8 🏢 XML საწარმოო სისტემებში

მსხვილ კორპორაციებში, ბანკებსა და სახელმწიფო სტრუქტურებში XML დღემდე ხერხემალია. ამ თავში ვნახავთ SOAP-ს, საბანკო და სამთავრობო ინტეგრაციებს, CRM/ERP პლატფორმებს და გავიგებთ — რატომ რჩება XML მძლავრად გამოყენებული JSON-ის პოპულარობის მიუხედავად.

SOAP

SOAP ვებ-სერვისები

SOAP (Simple Object Access Protocol) — ვებ-სერვისების პროტოკოლი, რომელიც მთლიანად XML-ზეა აგებული. ყოველი SOAP-შეტყობინება არის XML-დოკუმენტი მკაცრი სტრუქტურით: კონვერტი (Envelope) → სათაური (Header) → სხეული (Body).

SOAP-ის სიძლიერე — სიმკაცრე და სანდოობა: ფორმალური კონტრაქტი (WSDL, თავადაც XML), XSD-ვალიდაცია, უსაფრთხოების სტანდარტები (WS-Security), ტრანზაქციები. სწორედ ამიტომ ის ბანკებსა და კორპორაციებში პოპულარულია.

მაგალითები

SOAP-შეტყობინება

XML

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <auth>
      <token>ABC-123-XYZ</token>
    </auth>
  </soap:Header>
  <soap:Body>
    <getBalance>
      <account>GE29NB0000000101904917</account>
    </getBalance>
  </soap:Body>
</soap:Envelope>

💡 რჩევა: REST+JSON უფრო მსუბუქია, მაგრამ SOAP+XML იქ იმარჯვებს, სადაც კონტრაქტი, უსაფრთხოება და ფორმალური ვალიდაცია კრიტიკულია — ბანკი, დაზღვევა, ტელეკომი.

ბანკები

საბანკო ინტეგრაციები

ფინანსურ სამყაროში შეცდომა ფულს ნიშნავს — ამიტომ ფორმატი მკაცრი და ვალიდირებადი უნდა იყოს. XML ამ მოთხოვნებს იდეალურად ერგება.

ISO 20022 — გადახდების გლობალური XML-სტანდარტი (SEPA, SWIFT-ის ახალი თაობა).
FpML — ფინანსური წარმოებულების (derivatives) XML-ენა.
ბანკი-კლიენტი ინტეგრაცია — ანგარიშის ამონაწერები და გადახდები ხშირად XML-ით მიდის.

🌍 რეალური გამოყენება

როცა შენი ხელფასი ერთი ბანკიდან მეორეში გადადის, დიდი ალბათობით ამ ოპერაციის უკან XML-შეტყობინება დგას. XML ფინანსური ინფრასტრუქტურის უხილავი, მაგრამ ფუნდამენტური ნაწილია.

სახელმწიფო

სამთავრობო და საჯარო სისტემები

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

ელექტრონული ინვოისები / საგადასახადო: ბევრ ქვეყანაში სავალდებულო ე-ინვოისი XML-ფორმატშია (მაგ. UBL, e-invoicing სტანდარტები).
რეესტრები და მონაცემთა გაცვლა: უწყებებს შორის ინფორმაცია XML-ით იცვლება.
დოკუმენტბრუნვა: ფორმალური დოკუმენტები XML-სქემებით არის სტანდარტიზებული.

💡 რჩევა: სახელმწიფო სტანდარტები ათწლეულებით ცოცხლობს. XML-ის სტაბილურობა და მკაცრი ვალიდაცია მას ასეთი სისტემებისთვის ბუნებრივ არჩევანად აქცევს.

CRM

CRM პლატფორმები

CRM სისტემები (Salesforce, Microsoft Dynamics) მართავენ კლიენტებთან ურთიერთობას: კონტაქტები, გარიგებები, ისტორია. ისინი მუდმივად ცვლიან მონაცემს გარე სისტემებთან (ბუღალტერია, მარკეტინგი, ცენტრები).

ეს გაცვლა ხშირად XML-ით (და SOAP API-ებით) ხდება — განსაკუთრებით მსხვილ, „ლეგაცი" კორპორაციულ ინტეგრაციებში.

🌍 რეალური გამოყენება

როცა call-ცენტრი ხსნის კლიენტის ბარათს და ხედავს მის ისტორიას სხვა სისტემიდან, ფონზე სავარაუდოდ XML-მონაცემთა გაცვლა მუშაობს.

ERP

ERP პლატფორმები

ERP სისტემები (SAP, Oracle) აერთიანებენ კომპანიის ყველა პროცესს: საწყობი, წარმოება, ფინანსები, HR. ამდენი მოდულის ერთმანეთთან და გარე პარტნიორებთან დასაკავშირებლად საჭიროა მძლავრი, სტრუქტურირებული გაცვლის ფორმატი.

SAP-ის ცნობილი IDoc და სხვა მექანიზმები სწორედ XML-ს (ან XML-მსგავს სტრუქტურირებულ ფორმატს) ეყრდნობა.

🌍 რეალური გამოყენება

დიდი მწარმოებელი ქარხნის მიწოდების ჯაჭვი (supply chain) — შეკვეთები, ზედნადებები, მარაგი — წლების მანძილზე XML-შეტყობინებებით მუშაობს მომწოდებლებსა და ERP-ს შორის.

რატომ კვლავ XML?

რატომ რჩება XML მნიშვნელოვანი JSON-ის ეპოქაში

JSON-მა ვებ-API-ები დაიპყრო — და ეს კარგია. მაგრამ XML არსად წასულა. აი, რატომ:

გიგანტური ინსტალაციური ბაზა: ათწლეულების მანძილზე აგებული სისტემები მუშაობს და მუშაობს — მათი გადაწერა ძვირი და სარისკოა.
მკაცრი ვალიდაცია (XSD): XML-ს მოწიფული, ძლიერი სქემები აქვს — კრიტიკულია ფინანსებსა და მთავრობაში.
namespace-ები და ტრანსფორმაცია (XSLT): შესაძლებლობები, რომელთა JSON-ექვივალენტი ან არ არსებობს, ან ნაკლებად მოწიფულია.
დოკუმენტ-ცენტრული მონაცემი: შერეული შინაარსი (ტექსტი + მარკირება) XML-ის ბუნებრივი ძალაა (Office, წიგნები, კონტრაქტები).
ინდუსტრიული სტანდარტები: ISO 20022, UBL, HL7 (ჯანდაცვა), SOAP/WSDL — ეს ყველაფერი XML-ზე დგას.

დასკვნა: XML არ არის „მოძველებული" — ის სტანდარტია, რომელმაც ჩამოაყალიბა თანამედროვე მონაცემთა გაცვლა და დღემდე მართავს მსოფლიოს ყველაზე კრიტიკულ სისტემებს.

💡 რჩევა: პროფესიონალი დეველოპერი ორივეს ფლობს: JSON-ს ახალი ვებ-API-ებისთვის, XML-ს — საწარმოო ინტეგრაციის, კონფიგურაციისა და დოკუმენტური ამოცანებისთვის.

შეჯამება

📋 თავის შეჯამება

SOAP — XML-ზე აგებული ვებ-სერვისების პროტოკოლი (Envelope/Header/Body, WSDL, WS-Security).
ბანკები (ISO 20022, FpML), სახელმწიფო (ე-ინვოისი, რეესტრები), CRM (Salesforce) და ERP (SAP IDoc) ეყრდნობიან XML-ს.
XML რჩება, რადგან: უზარმაზარი ბაზა, მკაცრი XSD, namespace/XSLT, დოკუმენტურობა, ინდუსტრიული სტანდარტები.
XML არ არის JSON-ის კონკურენტი — ის სხვა, კრიტიკულ ამოცანებს ემსახურება.

ქვიზი

❓ ქვიზი

რაზეა აგებული SOAP?
პასუხი
მთლიანად XML-ზე (Envelope → Header → Body).
რა არის WSDL?
პასუხი
ვებ-სერვისის ფორმალური კონტრაქტი — თავადაც XML — რომელიც აღწერს, რა ოპერაციები და ფორმატებია ხელმისაწვდომი.
დაასახელე 2 მიზეზი, რატომ რჩება XML საწარმოოში JSON-ის მიუხედავად.
პასუხი
უზარმაზარი არსებული სისტემები + მკაცრი ვალიდაცია (XSD); ასევე namespace/XSLT და ინდუსტრიული სტანდარტები.

9 ⚖️ XML vs JSON

ეს თავი დეტალურად ადარებს XML-სა და JSON-ს ხუთ განზომილებაში: კითხვადობა, ვალიდაცია, სირთულე, წარმადობა და ინდუსტრიული გავრცელება. მიზანი — გასწავლოს, როგორ აირჩიო სწორი ფორმატი კონკრეტული ამოცანისთვის, და არა „რომელია უკეთესი".

JSON

JSON მოკლედ

JSON (JavaScript Object Notation) მონაცემის მსუბუქი ფორმატია, რომელიც key-value წყვილებსა და მასივებს იყენებს. ის JavaScript-იდან წარმოიშვა და ბუნებრივად ერგება ვებ-ს.

JSON-ის სიძლიერე: მცირე ზომა, სიმარტივე, სისწრაფე და პირდაპირი ასახვა პროგრამირების ობიექტებში.

მაგალითები

JSON სტრუქტურა

JSON

{
  "user": {
    "name": "გიორგი",
    "age": 25,
    "roles": ["admin", "editor"]
  }
}

კითხვადობა

ორივე ფორმატი ადამიანისთვის წაკითხვადია, მაგრამ განსხვავებულად.

JSON კომპაქტურია — ნაკლები „ხმაური", სწრაფი თვალის გადავლება. მცირე მონაცემზე უფრო სუფთად გამოიყურება.
XML უფრო „სიტყვიერია" (დამხურავი ტეგების გამო), მაგრამ თვით-აღწერადობა და სტრუქტურა დიდ, ღრმად ჩალაგებულ დოკუმენტებში მკაფიოა.

მაგალითები

იგივე მონაცემი — XML

XML

<user>
  <name>გიორგი</name>
  <age>25</age>
</user>

იგივე მონაცემი — JSON

JSON

{ "name": "გიორგი", "age": 25 }

💡 რჩევა: მცირე payload-ზე JSON უფრო კითხვადია; რთული, შერეული შინაარსის დოკუმენტზე (ტექსტი + მარკირება) XML-ი.

ვალიდაცია

აქ XML მკაფიოდ წინაა.

XML: მოწიფული, ძლიერი სქემები — XSD და DTD. ტიპები, შეზღუდვები, namespace-ები, ფორმატის წესები — ყველაფერი სტანდარტიზებული და ფართოდ მხარდაჭერილი.
JSON: არსებობს JSON Schema, მაგრამ ის უფრო ახალი და ნაკლებად დამკვიდრებულია; საწარმოო/მარეგულირებელ სფეროებში XSD-ს დონეს ვერ უტოლდება.

💡 რჩევა: თუ მონაცემს მკაცრი, ხელშეკრულებითი ვალიდაცია სჭირდება (ფინანსები, მთავრობა) — XML+XSD ჯერ კიდევ სტანდარტია.

სირთულე

JSON შესასწავლად მარტივია — რამდენიმე წესი და მზად ხარ. XML-ს მეტი ცნება აქვს: ატრიბუტები vs ელემენტები, namespace-ები, CDATA, entity-ები, DTD/XSD, XSLT, XPath.

ეს „სირთულე" ორმხრივია: ის რთულდება სასწავლად, მაგრამ სწორედ ეს დამატებითი შესაძლებლობებია, რაც XML-ს მძლავრს ხდის რთული ამოცანებისთვის.

💡 რჩევა: მარტივი ამოცანისთვის JSON-ის სიმარტივე უპირატესობაა; რთული, ფორმალური ამოცანისთვის XML-ის „სირთულე" სინამდვილეში სიმდიდრეა.

წარმადობა

JSON ჩვეულებრივ უფრო მცირე ზომისაა (ნაკლები სიმბოლო) და უფრო სწრაფად იპარსება, განსაკუთრებით ბრაუზერში. ამიტომ ის იდეალურია ხშირი, მსუბუქი ვებ-მოთხოვნებისთვის.

XML უფრო მოცულობითია (verbose), რაც ოდნავ მეტ ტრაფიკსა და დამუშავებას ნიშნავს. დიდი მონაცემის ნაკადისთვის არსებობს streaming პარსერები (SAX, StAX), რომლებიც მეხსიერებას ზოგავენ.

მნიშვნელობები

მნიშვნელობა	აღწერა
`ზომა`	JSON ჩვეულებრივ უფრო კომპაქტურია.
`პარსინგის სიჩქარე`	JSON ხშირად უფრო სწრაფი (განსაკუთრებით JS-ში).
`დიდი ნაკადი`	XML-ს აქვს მოწიფული streaming პარსერები (SAX/StAX).

💡 რჩევა: მაღალი სიხშირის, მცირე payload-ის ვებ-API-სთვის JSON უპირატესია; მაგრამ წარმადობის სხვაობა ხშირად მცირეა და გადამწყვეტი არ არის.

გავრცელება

ინდუსტრიული გავრცელება

JSON დომინირებს თანამედროვე ვებ/მობილურ API-ებში, public REST სერვისებსა და NoSQL ბაზებში.

XML დომინირებს საწარმოო ინტეგრაციაში, ფინანსებში (ISO 20022), ჯანდაცვაში (HL7), მთავრობაში, დოკუმენტურ ფორმატებში (Office) და SOAP ვებ-სერვისებში.

💡 რჩევა: ორივე ცოცხალია და მზარდი — უბრალოდ სხვადასხვა სფეროში. პროფესიონალი ორივეს ფლობს.

შედარების ცხრილი

შემაჯამებელი შედარების ცხრილი

მთავარი განსხვავებები ერთ შეხედვაში:

მნიშვნელობები

მნიშვნელობა	აღწერა
`კითხვადობა`	JSON — კომპაქტური; XML — სიტყვიერი, მაგრამ თვით-აღწერადი.
`ვალიდაცია`	XML — XSD/DTD (მოწიფული); JSON — JSON Schema (ახალი).
`სირთულე`	JSON — მარტივი; XML — მეტი ცნება, მეტი შესაძლებლობა.
`წარმადობა`	JSON — უფრო მცირე/სწრაფი; XML — verbose, აქვს streaming.
`ატრიბუტები`	XML — აქვს; JSON — არა (მხოლოდ key-value).
`კომენტარები`	XML — აქვს; JSON — სტანდარტში არა.
`namespace-ები`	XML — აქვს; JSON — არა.
`ტრანსფორმაცია`	XML — XSLT/XPath; JSON — ბუნებრივი არ აქვს.
`გავრცელება`	JSON — ვებ/მობილური API; XML — საწარმოო, ფინანსები, მთავრობა, დოკუმენტები.
`საუკეთესოა როცა`	JSON — მსუბუქი ვებ-გაცვლა; XML — ვალიდაცია, დოკუმენტურობა, საწარმოო ინტეგრაცია.

💡 რჩევა: დაამახსოვრე ეს ცხრილი — ის გამოცდასა და რეალურ პროექტში არჩევანის გასაკეთებლად საუკეთესო შპარგალკაა.

შეჯამება

📋 თავის შეჯამება

XML და JSON კონკურენტები კი არა, სხვადასხვა ამოცანის ხელსაწყოებია.
JSON: კომპაქტური, მარტივი, სწრაფი — იდეალური ვებ/მობილური API-სთვის.
XML: მკაცრი ვალიდაცია, namespace, XSLT, დოკუმენტურობა — იდეალური საწარმოო/ფორმალური ამოცანებისთვის.
ფორმატი აირჩიე ამოცანით, არა მოდით.

ქვიზი

❓ ქვიზი

რომელ ფორმატს აქვს მოწიფული, ფართოდ მხარდაჭერილი ვალიდაცია?
პასუხი
XML (XSD/DTD). JSON Schema არსებობს, მაგრამ უფრო ახალია.
რომელია ჩვეულებრივ უფრო კომპაქტური და სწრაფი?
პასუხი
JSON.
დაასახელე XML-ის 2 შესაძლებლობა, რომელიც JSON-ს სტანდარტში არ აქვს.
პასუხი
ატრიბუტები, კომენტარები, namespace-ები, ტრანსფორმაცია (XSLT) — ნებისმიერი ორი.
როგორ უნდა აირჩიო ფორმატი?
პასუხი
კონკრეტული ამოცანის მოთხოვნებით (ვალიდაცია, ზომა, გავრცელება), არა მოდით.

10 ⭐ საუკეთესო პრაქტიკა

საბოლოო თავი აჯამებს, როგორ დავწეროთ სუფთა, გამართული და მოვლადი XML. დავფარავთ: სახელდების კონვენციებს, სტრუქტურის დიზაინს, ზედმეტი სირთულის თავიდან აცილებას, დოკუმენტირებასა და მოვლადობას.

სახელდება

სახელდების კონვენციები

ელემენტებისა და ატრიბუტების კარგი სახელები XML-ს თვითონ ხდის დოკუმენტაციად. წესები:

სახელი იყოს აღწერითი და ლაკონური: <firstName>, არა <fn> და არა <theFirstNameOfTheUser>.
აირჩიე ერთი სტილი და დაიცავი: camelCase ან kebab-case (მაგ. <order-date>) — ოღონდ თანმიმდევრულად.
არ დაიწყო ციფრით; არ გამოიყენო space; xml-ით დაწყება დაცულია (reserved).
გამოიყენე სრულ სიტყვა, აბრევიატურების ნაცვლად, თუ ის გასაგებს ხდის მონაცემს.

მაგალითები

❌ ცუდი vs ✅ კარგი სახელდება

XML

<!-- ❌ -->
<x a="1"><d>2026-01-01</d></x>

<!-- ✅ -->
<order id="1">
  <orderDate>2026-01-01</orderDate>
</order>

სტრუქტურა

სტრუქტურის დიზაინი

კარგად დაგეგმილი სტრუქტურა მონაცემს გასაგებსა და დასამუშავებლად მარტივს ხდის.

💡 რჩევა: კარგი წესი: სტრუქტურა ისე დააპროექტე, რომ უცხო ადამიანმა XML ერთი გადახედვით გაიგოს — დამატებითი ახსნის გარეშე.

✓ საუკეთესო პრაქტიკა

მთავარი მონაცემი — ელემენტებად; მეტამონაცემი (id, lang, type) — ატრიბუტებად.
განმეორებად ერთეულებს მიეცი ერთი შემფუთველი მშობელი (<items> → ბევრი <item>).
root ელემენტს მიეცი მკაფიო, შინაარსიანი სახელი.
ერთგვაროვანი მონაცემი ჩაალაგე თანმიმდევრულად — ერთნაირი ერთეულები ერთნაირად გამოიყურებოდეს.
მოერიდე ღრმა, ზედმეტ ჩალაგებას — სტრუქტურა ბრტყელი ფენებით უფრო კითხვადია.

სიმარტივე

ზედმეტი სირთულის თავიდან აცილება

XML-ის ბევრი შესაძლებლობა ცდუნებაა — მაგრამ ყველაფერი ყოველთვის საჭირო არ არის. „რაც უფრო მარტივი, მით უკეთესი".

💡 რჩევა: სანამ რთულ მექანიზმს (namespace, CDATA, ღრმა ხე) დაამატებ, იკითხე: „ეს ნამდვილად სჭირდება ამ მონაცემს?"

✗ ხშირი შეცდომები

ზედმეტად ღრმა ჩალაგება — 7-8 დონე ანელებს კითხვადობასა და დამუშავებას.
namespace-ების გამოყენება იქ, სადაც ისინი საჭირო არ არის — ზრდის სირთულეს უმიზნოდ.
ერთი და იგივე მონაცემის ჩაწერა ერთდროულად ატრიბუტადაც და ელემენტადაც.
CDATA-ს გადამეტებული გამოყენება ჩვეულებრივი ტექსტისთვის.
ზედმეტად „ჭკვიანი" სტრუქტურა, რომელიც მხოლოდ ავტორს ესმის.

დოკუმენტირება

XML, რომელსაც სხვებიც იყენებენ, უნდა იყოს დოკუმენტირებული.

XSD როგორც დოკუმენტაცია: სქემა თავად აღწერს ფორმატს — ის „ცოცხალი" დოკუმენტია, რომელიც კოდთან ერთად მოწმდება.
კომენტარები: ახსენი არასტანდარტული გადაწყვეტილებები პირდაპირ ფაილში ().
მაგალითები: დაურთე ფორმატს ნიმუშ-ფაილი — ერთი კარგი მაგალითი ღირს ათი აბზაცის ახსნად.

💡 რჩევა: საუკეთესო დოკუმენტაცია = მკაფიო XSD + რამდენიმე კარგი ნიმუში + მცირე კომენტარები რთულ ადგილებში.

მოვლადობა

XML-ფორმატი ხშირად წლების მანძილზე ცოცხლობს, ამიტომ ის ცვლილებებისთვის მზად უნდა იყოს.

💡 რჩევა: უკუ-თავსებადობა (backward compatibility) ფორმატის დიზაინის ოქროს წესია: ახალი ვერსია ძველ მონაცემს არ უნდა „ამტვრევდეს".

✓ საუკეთესო პრაქტიკა

დაამატე ვერსია (მაგ. ატრიბუტი version="1.0" root-ზე) — მომავალში თავსებადობას დააზოგავს.
ახალი ველები დაამატე არჩევითად, რომ ძველი დოკუმენტები არ „გატყდეს".
დაიცავი თანმიმდევრული სტილი მთელ პროექტში — ერთი ფორმატი, ერთი კონვენცია.
შეინახე XSD ვერსიების კონტროლში (Git) კოდთან ერთად.

ხშირი შეცდომები

⚠️ ხშირი შეცდომები (შემაჯამებელი)

მთელი წიგნის ყველაზე ხშირი შეცდომები ერთად:

💡 რჩევა: ეჭვის შემთხვევაში — გახსენი XML ბრაუზერში ან online ვალიდატორში: ის well-formed შეცდომებს ხაზის ნომრით გაჩვენებს.

✗ ხშირი შეცდომები

დაუხურავი ან არასწორად ჩალაგებული ტეგები.
რეგისტრის შეუსაბამობა გამხსნელსა და დამხურავ ტეგს შორის.
ერთზე მეტი root ელემენტი.
ატრიბუტის მნიშვნელობა ბრჭყალების გარეშე.
შიშველი სპეც-სიმბოლოები (&, <) entity-ით ჩაუნაცვლებლად.
XML დეკლარაციის წინ space ან ცარიელი ხაზი.
არასწორი encoding — ქართულის „გადარევა".
ვალიდაციაზე უარის თქმა იქ, სადაც მონაცემის სიზუსტე კრიტიკულია.

საბოლოო შეჯამება

📋 თავის შეჯამება და წიგნის დასკვნა

სახელდება: აღწერითი, თანმიმდევრული, reserved-ის გარეშე.
სტრუქტურა: ელემენტი მონაცემს, ატრიბუტი მეტამონაცემს; შემფუთველი მშობელი განმეორებადებს.
სიმარტივე: მოერიდე ზედმეტ ჩალაგებასა და უმიზნო namespace/CDATA-ს.
დოკუმენტირება: XSD + ნიმუშები + კომენტარები.
მოვლადობა: ვერსირება, არჩევითი ახალი ველები, უკუ-თავსებადობა, Git.

წიგნის მთავარი გზავნილი: XML არ არის უბრალოდ ძველი ტექნოლოგია — ის ფუნდამენტური სტანდარტია, რომელმაც ჩამოაყალიბა მონაცემთა აღწერის, ვალიდაციის, ტრანსფორმაციისა და ინტეგრაციის თანამედროვე პრაქტიკა. JSON-ის ეპოქაშიც XML მართავს მსოფლიოს ყველაზე კრიტიკულ სისტემებს — ბანკებს, მთავრობებს, ERP/CRM პლატფორმებს. ამიტომ XML-ის გაგება ნებისმიერი დეველოპერის საბაზისო ცოდნის ნაწილია, თუნდაც ის ყოველდღიურად JSON-ს იყენებდეს.

💡 რჩევა: გილოცავ — დაასრულე XML-ის სრული კურსი! ახლა შეგიძლია წაიკითხო, დაწერო, დაავალიდირო, გარდაქმნა და ინტეგრირებაში გამოიყენო XML.

საფინალო სავარჯიშოები

✍️ საფინალო სავარჯიშოები

დააპროექტე სრული XML + XSD ერთი რეალური დომენისთვის (მაგ. ონლაინ-კურსების პლატფორმა: კურსები, გაკვეთილები, სტუდენტები).
აიღე შენი ერთ-ერთი ადრინდელი სავარჯიშო და გადახედე: დაიცავი თუ არა ამ თავის სახელდებისა და სტრუქტურის წესები? გააუმჯობესე.
დაწერე მოკლე XSLT, რომელიც შენს XML-ს HTML ცხრილად აქცევს.
ჩამოწერე, შენ მიერ არჩეულ პროექტში XML-ს თუ JSON-ს გამოიყენებდი და დაასაბუთე არჩევანი ამ წიგნის კრიტერიუმებით.

მნიშვნელობა	აღწერა
`&lt;`	`<` (less than) — ნაკლები.
`&gt;`	`>` (greater than) — მეტი.
`&amp;`	`&` (ampersand) — ეს და.
`&apos;`	`'` (apostrophe) — აპოსტროფი.
`&quot;`	`"` (quotation mark) — ბრჭყალი.

მნიშვნელობა	აღწერა
`&lt;`	`<` (less than) — ნაკლები.
`&gt;`	`>` (greater than) — მეტი.
`&amp;`	`&` (ampersand) — ეს და.
`&apos;`	`'` (apostrophe) — აპოსტროფი.
`&quot;`	`"` (quotation mark) — ბრჭყალი.

XML — სრული ქართულენოვანი გზამკვლევი

1 📘 შესავალი XML-ში

მაგალითები

პირველი XML დოკუმენტი

🌍 რეალური გამოყენება

დაკავშირებული თემები:

დაკავშირებული თემები:

დაკავშირებული თემები:

მნიშვნელობები

მაგალითები

იგივე მონაცემი — CSV (გაუგებარი)

იგივე მონაცემი — XML (ცხადი)

დაკავშირებული თემები:

მნიშვნელობები

მაგალითები

HTML — გარეგნობა (presentation)

XML — მნიშვნელობა (data)

✗ ხშირი შეცდომები

დაკავშირებული თემები:

მაგალითები

XML

JSON (იგივე მონაცემი)

დაკავშირებული თემები:

მნიშვნელობები

✓ საუკეთესო პრაქტიკა

დაკავშირებული თემები:

2 🔤 XML სინტაქსი

სინტაქსი

მნიშვნელობები

✗ ხშირი შეცდომები

დაკავშირებული თემები:

სინტაქსი

მნიშვნელობები

მაგალითები

ელემენტის ნაწილები

დაკავშირებული თემები:

მაგალითები

❌ არასწორი (დაუხურავი)

✅ სწორი

✗ ხშირი შეცდომები

დაკავშირებული თემები:

მაგალითები

❌ რეგისტრი არ ემთხვევა

✅ ემთხვევა

დაკავშირებული თემები:

სინტაქსი

მაგალითები

ატრიბუტები vs. ჩა-ელემენტები

✓ საუკეთესო პრაქტიკა

✗ ხშირი შეცდომები

დაკავშირებული თემები:

მაგალითები

❌ გადაკვეთილი (overlapping)

✅ სწორად ჩალაგებული

რეალური იერარქია

დაკავშირებული თემები:

მაგალითები

❌ ორი root — შეცდომა

✅ ერთი root მოიცავს ყველაფერს

დაკავშირებული თემები:

სინტაქსი

მაგალითები

კომენტარი დოკუმენტში

✗ ხშირი შეცდომები

დაკავშირებული თემები:

მნიშვნელობები

მაგალითები

entity-ები მონაცემში

CDATA — ნედლი ტექსტი

✗ ხშირი შეცდომები

დაკავშირებული თემები:

მნიშვნელობები

დაკავშირებული თემები:

დაკავშირებული თემები:

3 🌳 მონაცემთა სტრუქტურირება

დაკავშირებული თემები:

მაგალითები

ხის ვიზუალი (ASCII)

იგივე ხე XML-ად

დაკავშირებული თემები:

მნიშვნელობა	აღწერა
`&lt;`	`<` (less than) — ნაკლები.
`&gt;`	`>` (greater than) — მეტი.
`&amp;`	`&` (ampersand) — ეს და.
`&apos;`	`'` (apostrophe) — აპოსტროფი.
`&quot;`	`"` (quotation mark) — ბრჭყალი.