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 утасны утаснуудад зориулсан автомат тохиргооны файлын форматыг авдаг. Ийм файлууд нь TFTP-ээр дамжуулан XML хүсэлтийн файлуудыг татаж авахыг шаарддаг бөгөөд энэ нь ... Ерөнхийдөө ийм нэг файлаас хэсэгчлэн энд оруулав.
<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 - толь бичигт байгаа элементүүдийн боломжит хослолын тоо, бусад боломжит хувьсагчдыг бид хараахан тооцоогүй байна.
Гэсэн хэдий ч, хэрэв та зөвхөн өгөгдөл дамжуулахыг хүсч байвал үүнийг машинд унших боломжтой баримт бичгийг ашиглах нь үр дүнгүй болно. Энэ нь загварыг ашигладаг бөгөөд энэ тохиолдолд илүүдэхгүй, энэ нь зөвхөн саад болно. Үүнээс гадна, эх өгөгдлийг задлахын тулд та програм бичих хэрэгтэй болно. Хэзээ нэгэн цагт баримт болгон форматлахгүй (CSS эсвэл XSLT эсвэл хоёуланг нь ашиглах гэх мэт) ямар нэгэн зүйлд XML ашиглах нь ямар ч утгагүй, учир нь энэ нь үүнийг хийх гол (хэрэв цорын ганц биш бол) шалтгаан юм. баримт бичгийн загварт.
Түүнээс гадна, XML-д тоо (эсвэл логикийн илэрхийлэл эсвэл бусад өгөгдлийн төрлүүд) гэсэн ойлголт байдаггүй тул энэ форматаар илэрхийлэгдсэн бүх тоо нь зөвхөн нэмэлт текст гэж тооцогддог. Өгөгдлийг гаргаж авахын тулд схем болон түүний илэрхийлэгдэж буй харгалзах өгөгдөлтэй хамаарлыг мэдэх шаардлагатай. Та мөн контекст дээр үндэслэн тухайн текстийн элемент хэзээ тоог илэрхийлж, тоо болгон хувиргах гэх мэтийг мэдэх хэрэгтэй.
Тиймээс XML баримтаас өгөгдөл гаргаж авах үйл явц нь жишээлбэл, тоон мэдээллийн олон хуудас бүрдүүлдэг хүснэгтүүдийг агуулсан сканнердсан баримт бичгүүдийг таних үйл явцаас тийм ч их ялгаатай биш юм. Тиймээ, үүнийг зарчмын хувьд хийх боломжтой, гэхдээ энэ нь өөр сонголт байхгүй тохиолдолд эцсийн арга хэмжээ авахаас бусад тохиолдолд хамгийн оновчтой арга биш юм. Үндэслэлтэй шийдэл бол баримт бичгийн загварт суулгаагүй анхны өгөгдлийн дижитал хуулбарыг олох явдал бөгөөд өгөгдлийг текстийн тусгай дүрслэлтэй хослуулсан байдаг.
XML нь бизнест түгээмэл байдаг нь намайг гайхшруулахгүй байна. Үүний шалтгаан нь баримт бичгийн хэлбэр (цаасан дээр) нь бизнест ойлгомжтой, танил болсонтой холбоотой бөгөөд тэд танил, ойлгомжтой загварыг үргэлжлүүлэн ашиглахыг хүсч байна. Үүнтэй ижил шалтгаанаар бизнесүүд машинд унших боломжтой форматын оронд PDF баримт бичгийг ихэвчлэн ашигладаг - учир нь тэдгээр нь тодорхой физик хэмжээтэй хэвлэсэн хуудасны үзэл баримтлалтай холбоотой хэвээр байна. Энэ нь хэзээ ч хэвлэгдэх боломжгүй баримт бичигт ч хамаатай (жишээлбэл, бүртгэлийн баримт бичгийн 8000 хуудас PDF). Энэ үүднээс авч үзвэл бизнест XML-г ашиглах нь үндсэндээ скеуоморфизмын илрэл юм. Хязгаарлагдмал хэмжээтэй хэвлэсэн хуудасны зүйрлэлийг хүмүүс ойлгож, хэвлэсэн баримт бичигт үндэслэн бизнесийн үйл явцыг хэрхэн бий болгохыг ойлгодог. Хэрэв энэ нь таны гарын авлага бол машинд уншигдахуйц физик хэмжээ хязгааргүй баримт бичиг буюу XML баримт бичиг нь шинэлэг санааг илтгэж, танил, эвтэйхэн баримт бичиг болно. Энэ нь тэднийг мэдээлэл өгөх буруу, хэт скеуоморф хэлбэр хэвээр үлдэхэд саад болохгүй.
Өнөөдрийг хүртэл миний мэдэх цорын ганц XML схем бол XHTML болон DocBook формат юм.
Эх сурвалж: www.habr.com