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 հեռախոսակապի հեռախոսների համար: Նման ֆայլերը պահանջում են 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 - բառարանում տարրերի հնարավոր համակցությունների քանակը, և մենք դեռ հաշվի չենք առել այլ հնարավոր փոփոխականներ:

Այնուամենայնիվ, դրանից բխում է նաև, որ եթե ցանկանում եք փոխանցել միայն տվյալներ, ապա դրա համար մեքենայաընթեռնելի փաստաթղթի օգտագործումը արդյունավետ չի լինի: Այն օգտագործում է մոդել, որն այս դեպքում միայն կխանգարի։ Բացի այդ, աղբյուրի տվյալները հանելու համար ձեզ հարկավոր է ծրագիր գրել։ Դժվար թե իմաստ ունենա XML-ն օգտագործել այն բանի համար, որը ինչ-որ պահի չի ձևակերպվի որպես փաստաթուղթ (ասենք, օգտագործելով CSS կամ XSLT, կամ երկուսն էլ), քանի որ դա է դա անելու հիմնական (եթե ոչ միակ) պատճառը փաստաթղթի մոդելին:

Ավելին, քանի որ XML-ը չունի թվերի հասկացություն (կամ բուլյան արտահայտություններ կամ տվյալների այլ տեսակներ), այս ձևաչափով ներկայացված բոլոր թվերը համարվում են ընդամենը լրացուցիչ տեքստ: Տվյալներ հանելու համար պետք է հայտնի լինի սխեման և դրա կապը համապատասխան արտահայտվող տվյալների հետ: Դուք նաև պետք է իմանաք, թե համատեքստից ելնելով, երբ կոնկրետ տեքստային տարրը ներկայացնում է թիվ և պետք է փոխարկվի թվի և այլն:

Այսպիսով, XML փաստաթղթերից տվյալների արդյունահանման գործընթացն այնքան էլ չի տարբերվում սկանավորված փաստաթղթերի ճանաչման գործընթացից, որոնք պարունակում են, օրինակ, թվային տվյալների բազմաթիվ էջեր կազմող աղյուսակներ: Այո, դա հնարավոր է անել սկզբունքորեն, բայց սա ամենաօպտիմալ միջոցը չէ, բացառությամբ վերջին միջոցի, երբ բացարձակապես այլ տարբերակներ չկան։ Խելամիտ լուծում է պարզապես գտնել բնօրինակ տվյալների թվային պատճենը, որը ներառված չէ փաստաթղթի մոդելում, որը միավորում է տվյալները իր հատուկ տեքստային ներկայացման հետ:

Ասել է թե՝ ինձ ամենևին էլ չի զարմացնում, որ XML-ը հայտնի է բիզնեսում: Սրա պատճառն այն է, որ փաստաթղթի ձևաչափը (թղթի վրա) հասկանալի և ծանոթ է բիզնեսին, և նրանք ցանկանում են շարունակել օգտագործել ծանոթ և հասկանալի մոդել: Նույն պատճառով, ձեռնարկությունները շատ հաճախ օգտագործում են PDF փաստաթղթեր՝ ավելի շատ մեքենայական ընթեռնելի ձևաչափերի փոխարեն, քանի որ դրանք դեռ կապված են որոշակի ֆիզիկական չափերով տպագիր էջի գաղափարի հետ: Սա նույնիսկ վերաբերում է այն փաստաթղթերին, որոնք դժվար թե երբևէ տպագրվեն (օրինակ՝ ռեեստրի փաստաթղթերի 8000 էջանոց PDF): Այս տեսանկյունից XML-ի օգտագործումը բիզնեսում, ըստ էության, սկեյոմորֆիզմի դրսեւորում է։ Մարդիկ հասկանում են սահմանափակ չափի տպագիր էջի փոխաբերական գաղափարը և հասկանում են, թե ինչպես ստեղծել բիզնես գործընթացներ՝ հիմնված տպագիր փաստաթղթերի վրա: Եթե ​​դա ձեր ուղեցույցն է, փաստաթղթերը, առանց ֆիզիկական չափի սահմանափակումների, որոնք մեքենայական ընթեռնելի են՝ XML փաստաթղթերը, ներկայացնում են նորարարություն՝ միաժամանակ լինելով փաստաթղթերի ծանոթ և հարմարավետ գործընկեր: Սա չի խանգարում նրանց մնալ տվյալների ներկայացման ոչ ճիշտ և չափազանց սքևոմորֆ ձև:

Մինչ օրս միակ XML սխեմաները, որոնց մասին ես գիտեմ, որոնց մասին կարող եմ իրականում անվանել ձևաչափի վավեր օգտագործում, XHTML և DocBook են:

Source: www.habr.com