XML প্রায় সবসময় অপব্যবহার করা হয়

XML ভাষা 1996 সালে উদ্ভাবিত হয়েছিল। যত তাড়াতাড়ি এটি উপস্থিত হয়েছিল তার প্রয়োগের সম্ভাবনাগুলি ইতিমধ্যেই ভুল বোঝাবুঝি হতে শুরু করেছিল এবং যে উদ্দেশ্যে তারা এটিকে খাপ খাইয়ে নেওয়ার চেষ্টা করেছিল, এটি সর্বোত্তম পছন্দ ছিল না।

এটা বলতে কোন অত্যুক্তি হবে না যে 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" />

বিষয়গুলিকে আরও খারাপ করার জন্য, অভিধান প্রকাশের একটি অসামান্য উপায় হিসাবে আমাদের এখানে খালি স্ট্রিংয়ের একটি শব্দার্থিক টীকা নেই - এই সময় "অভিধান" সরাসরি মূল উপাদানের বৈশিষ্ট্য হিসাবে এনকোড করা হয়েছে। এটি একটি উপাদানের প্রদত্ত অ্যাট্রিবিউট নামের সেটটিকে অনির্ধারিত এবং গতিশীল করে তোলে। অধিকন্তু, এটি দেখায় যে সমস্ত লেখক সত্যিই একটি সাধারণ কী-মান সিনট্যাক্স প্রকাশ করতে চেয়েছিলেন, কিন্তু পরিবর্তে তিনি এক্সএমএল প্রয়োগ করার জন্য একেবারে উদ্ভট সিদ্ধান্ত নিয়েছিলেন, কেবলমাত্র অ্যাট্রিবিউট সিনট্যাক্স ব্যবহার করার জন্য একটি উপসর্গ হিসাবে একটি খালি উপাদান ব্যবহার করতে বাধ্য করেছিলেন। এবং আমি প্রায়ই এই ধরনের স্কিম জুড়ে আসা.

<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 স্কিমা, 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 এর একটি অ্যানালগ হিসাবে, আমরা শর্তসাপেক্ষে একটি মেশিন-পঠনযোগ্য নথি নিতে পারি। যদিও এটি মেশিন রিডেবল হওয়ার উদ্দেশ্যে করা হয়েছে, এটি রূপকভাবে নথিতে উল্লেখ করে এবং এই দৃষ্টিকোণ থেকে পিডিএফ ডকুমেন্টের সাথে তুলনীয়, যা বেশিরভাগ ক্ষেত্রেই মেশিন রিডেবল হয় না।

উদাহরণস্বরূপ, XML-এ উপাদানগুলির ক্রম গুরুত্বপূর্ণ। কিন্তু JSON-এ, বস্তুর মধ্যে কী-মানের জোড়ার ক্রম অর্থহীন এবং অনির্ধারিত। আপনি যদি কী-মানের জোড়াগুলির একটি অ-ক্রমবিহীন অভিধান পেতে চান, তাহলে সেই ফাইলটিতে উপাদানগুলি যে প্রকৃত ক্রমে উপস্থিত হয় তা কোন ব্যাপার না। কিন্তু আপনি এই ডেটা থেকে বিভিন্ন ধরণের ডেটা তৈরি করতে পারেন। নথিপত্র, কারণ নথিতে একটি নির্দিষ্ট আদেশ আছে। রূপকভাবে, এটি কাগজের একটি নথির সাথে সাদৃশ্যপূর্ণ, যদিও এটির একটি প্রিন্টআউট বা পিডিএফ ফাইলের বিপরীতে শারীরিক মাত্রা নেই।

একটি সঠিক XML অভিধান উপস্থাপনের আমার উদাহরণ অভিধানে উপাদানগুলির ক্রম দেখায়, JSON উপস্থাপনার বিপরীতে। আমি এই আদেশটি উপেক্ষা করতে পারি না: এই রৈখিকতা নথি মডেল এবং XML বিন্যাসে অন্তর্নিহিত। কেউ কেউ এই এক্সএমএল ডকুমেন্টের ব্যাখ্যা করার সময় অর্ডারটিকে উপেক্ষা করতে বেছে নিতে পারেন, কিন্তু এই বিষয়ে তর্ক করার কোন মানে নেই যেহেতু সমস্যাটি নিজেই ফর্ম্যাটের আলোচনার সুযোগের বাইরে। তাছাড়া, আপনি যদি ব্রাউজারে একটি ক্যাসকেডিং স্টাইল শীট সংযুক্ত করে দস্তাবেজটিকে দর্শনযোগ্য করে তোলেন, তাহলে আপনি দেখতে পাবেন যে অভিধানের উপাদানগুলি একটি নির্দিষ্ট ক্রমে প্রদর্শিত হবে এবং অন্য কোনটিতে নয়।

অন্য কথায়, একটি অভিধান (স্ট্রাকচার্ড ডেটার একটি অংশ) রূপান্তর করা যেতে পারে n বিভিন্ন সম্ভাব্য নথি (এক্সএমএল, পিডিএফ, কাগজ, ইত্যাদি), যেখানে n - অভিধানে উপাদানগুলির সম্ভাব্য সংমিশ্রণের সংখ্যা, এবং আমরা এখনও অন্যান্য সম্ভাব্য ভেরিয়েবলগুলি বিবেচনা করি নি।

যাইহোক, এটিও অনুসরণ করে যে আপনি যদি শুধুমাত্র ডেটা স্থানান্তর করতে চান তবে এর জন্য একটি মেশিন-পাঠযোগ্য নথি ব্যবহার করা কার্যকর হবে না। এটি একটি মডেল ব্যবহার করে, যা এই ক্ষেত্রে অপ্রয়োজনীয়; এটি শুধুমাত্র পথ পাবে। উপরন্তু, উৎস তথ্য নিষ্কাশন করার জন্য, আপনাকে একটি প্রোগ্রাম লিখতে হবে। এমন কিছুর জন্য XML ব্যবহার করার ক্ষেত্রে খুব কমই কোন বিন্দু আছে যা কিছু সময়ে নথি হিসাবে ফর্ম্যাট করা হবে না (বলুন, CSS বা XSLT ব্যবহার করে, বা উভয়ই), কারণ এটি করার প্রধান (যদি একমাত্র না) কারণ এটি মেনে চলা। নথি মডেলের কাছে।

অধিকন্তু, যেহেতু XML-এ সংখ্যার কোন ধারণা নেই (বা বুলিয়ান এক্সপ্রেশন, বা অন্যান্য ডেটা টাইপ), এই বিন্যাসে উপস্থাপিত সমস্ত সংখ্যা শুধুমাত্র অতিরিক্ত পাঠ্য হিসাবে বিবেচিত হয়। ডেটা বের করতে, স্কিমা এবং সংশ্লিষ্ট ডেটার সাথে এর সম্পর্ক প্রকাশ করা আবশ্যক। আপনাকে এটিও জানতে হবে কখন, প্রেক্ষাপটের উপর ভিত্তি করে, একটি নির্দিষ্ট পাঠ্য উপাদান একটি সংখ্যাকে প্রতিনিধিত্ব করে এবং একটি সংখ্যায় রূপান্তর করা উচিত, ইত্যাদি।

সুতরাং, XML নথিগুলি থেকে ডেটা আহরণের প্রক্রিয়াটি স্ক্যান করা নথিগুলিকে স্বীকৃতি দেওয়ার প্রক্রিয়া থেকে এতটা আলাদা নয়, উদাহরণস্বরূপ, সাংখ্যিক ডেটার অনেকগুলি পৃষ্ঠা তৈরি করে। হ্যাঁ, নীতিগতভাবে এটি করা সম্ভব, তবে এটি সবচেয়ে অনুকূল উপায় নয়, শেষ অবলম্বন ছাড়া, যখন একেবারে অন্য কোনও বিকল্প নেই। একটি যুক্তিসঙ্গত সমাধান হল আসল ডেটার একটি ডিজিটাল কপি খুঁজে পাওয়া যা একটি নথির মডেলে এমবেড করা নেই যা ডেটাকে এর নির্দিষ্ট পাঠ্য উপস্থাপনার সাথে একত্রিত করে।

এটি বলেছিল, এটি আমাকে মোটেও অবাক করে না যে XML ব্যবসায় জনপ্রিয়। এর কারণ সঠিকভাবে হল যে নথির বিন্যাসটি (কাগজে) ব্যবসায়ের জন্য বোধগম্য এবং পরিচিত, এবং তারা একটি পরিচিত এবং বোধগম্য মডেল ব্যবহার চালিয়ে যেতে চায়। একই কারণে, ব্যবসাগুলিও প্রায়শই আরও মেশিন-পাঠযোগ্য বিন্যাসের পরিবর্তে PDF নথি ব্যবহার করে - কারণ তারা এখনও একটি নির্দিষ্ট শারীরিক আকারের সাথে একটি মুদ্রিত পৃষ্ঠার ধারণার সাথে আবদ্ধ। এটি এমন নথিগুলির ক্ষেত্রেও প্রযোজ্য যেগুলি কখনও মুদ্রিত হওয়ার সম্ভাবনা নেই (উদাহরণস্বরূপ, রেজিস্ট্রি ডকুমেন্টেশনের একটি 8000-পৃষ্ঠা পিডিএফ)। এই দৃষ্টিকোণ থেকে, ব্যবসায় XML ব্যবহার মূলত skeuomorphism এর একটি প্রকাশ। লোকেরা সীমিত আকারের একটি মুদ্রিত পৃষ্ঠার রূপক ধারণা বোঝে এবং মুদ্রিত নথির উপর ভিত্তি করে কীভাবে ব্যবসায়িক প্রক্রিয়া তৈরি করতে হয় তা তারা বোঝে। যদি এটি আপনার নির্দেশিকা হয়, দস্তাবেজগুলি শারীরিক আকারের সীমাবদ্ধতা ছাড়াই যা মেশিন-পঠনযোগ্য—XML নথি—একটি পরিচিত এবং আরামদায়ক নথির প্রতিপক্ষ হওয়ার সময় উদ্ভাবনের প্রতিনিধিত্ব করে৷ এটি তাদের ডেটা উপস্থাপনের একটি ভুল এবং অত্যধিক স্কিওমরফিক উপায় থেকে বিরত রাখে না।

আজ অবধি, একমাত্র XML স্কিমা যেগুলি সম্পর্কে আমি জানি যে আমি সত্যই বিন্যাসের একটি বৈধ ব্যবহার বলতে পারি সেগুলি হল XHTML এবং DocBook৷

উত্স: www.habr.com