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 کے ینالاگ کے طور پر، ہم مشروط طور پر مشین پڑھنے کے قابل دستاویز لے سکتے ہیں۔ اگرچہ اس کا مقصد مشین سے پڑھنے کے قابل ہونا ہے، لیکن یہ استعاراتی طور پر دستاویزات سے مراد ہے، اور اس نقطہ نظر سے دراصل پی ڈی ایف دستاویزات سے موازنہ کیا جا سکتا ہے، جو اکثر مشین سے پڑھنے کے قابل نہیں ہوتے ہیں۔
مثال کے طور پر، XML میں عناصر کی ترتیب اہمیت رکھتی ہے۔ لیکن JSON میں، اشیاء کے اندر کلیدی قدر کے جوڑوں کی ترتیب بے معنی اور غیر متعینہ ہے۔ اگر آپ کلیدی قدر کے جوڑوں کی ایک غیر ترتیب شدہ لغت حاصل کرنا چاہتے ہیں، تو اصل ترتیب جس میں عناصر اس فائل میں ظاہر ہوتے ہیں کوئی فرق نہیں پڑتا۔ لیکن آپ اس ڈیٹا سے بہت سے مختلف قسم کے ڈیٹا بنا سکتے ہیں۔ دستاویزات کیکیونکہ دستاویز میں ایک خاص ترتیب ہے۔ استعاراتی طور پر، یہ کاغذ پر موجود کسی دستاویز کے مشابہ ہے، حالانکہ اس کی طبعی جہتیں نہیں ہیں، پرنٹ آؤٹ یا پی ڈی ایف فائل کے برعکس۔
ایک مناسب XML لغت کی نمائندگی کی میری مثال لغت میں عناصر کی ترتیب کو ظاہر کرتی ہے، جیسا کہ JSON نمائندگی کے برخلاف ہے۔ میں اس ترتیب کو نظر انداز نہیں کر سکتا: یہ خطوط دستاویز کے ماڈل اور XML فارمیٹ میں موروثی ہے۔ کچھ لوگ اس XML دستاویز کی تشریح کرتے وقت آرڈر کو نظر انداز کرنے کا انتخاب کر سکتے ہیں، لیکن اس کے بارے میں بحث کرنے کا کوئی فائدہ نہیں ہے کیونکہ یہ مسئلہ خود فارمیٹ کی بحث کے دائرہ سے باہر ہے۔ مزید برآں، اگر آپ دستاویز کو براؤزر میں دیکھنے کے قابل بناتے ہیں تو اس کے ساتھ ایک جھرنے والی اسٹائل شیٹ منسلک کرتے ہیں، آپ دیکھیں گے کہ لغت کے عناصر ایک خاص ترتیب میں ظاہر ہوتے ہیں اور کسی اور ترتیب میں نہیں۔
دوسرے الفاظ میں، ایک لغت (سٹرکچرڈ ڈیٹا کا ایک ٹکڑا) میں تبدیل کیا جا سکتا ہے۔ n مختلف ممکنہ دستاویزات (XML، PDF، کاغذ، وغیرہ میں)، جہاں n - لغت میں عناصر کے ممکنہ امتزاج کی تعداد، اور ہم نے ابھی تک دیگر ممکنہ متغیرات کو مدنظر نہیں رکھا ہے۔
تاہم، یہ بھی مندرجہ ذیل ہے کہ اگر آپ صرف ڈیٹا منتقل کرنا چاہتے ہیں، تو اس کے لیے مشین سے پڑھنے کے قابل دستاویز کا استعمال مؤثر نہیں ہوگا۔ یہ ایک ماڈل استعمال کرتا ہے، جو اس معاملے میں ضرورت سے زیادہ ہے؛ یہ صرف راستے میں آئے گا۔ اس کے علاوہ، سورس ڈیٹا کو نکالنے کے لیے، آپ کو ایک پروگرام لکھنا ہوگا۔ کسی ایسی چیز کے لیے XML استعمال کرنے کا شاید ہی کوئی فائدہ ہو جسے کسی وقت دستاویز کے طور پر فارمیٹ نہ کیا جائے (کہیں کہ CSS یا XSLT، یا دونوں کا استعمال کرتے ہوئے)، کیوں کہ ایسا کرنے کی بنیادی (اگر واحد نہیں) وجہ ہے۔ دستاویز کے ماڈل پر۔
مزید برآں، چونکہ XML میں نمبرز (یا بولین ایکسپریشنز، یا ڈیٹا کی دیگر اقسام) کا کوئی تصور نہیں ہے، اس لیے اس فارمیٹ میں دکھائے گئے تمام نمبروں کو صرف اضافی متن سمجھا جاتا ہے۔ اعداد و شمار کو نکالنے کے لیے، اسکیما اور اس کے متعلقہ اعداد و شمار سے تعلق کو معلوم ہونا چاہیے۔ آپ کو یہ بھی جاننے کی ضرورت ہے کہ سیاق و سباق کی بنیاد پر، ایک مخصوص متن کا عنصر کب کسی نمبر کی نمائندگی کرتا ہے اور اسے نمبر میں تبدیل کیا جانا چاہیے، وغیرہ۔
اس طرح، XML دستاویزات سے ڈیٹا نکالنے کا عمل اسکین شدہ دستاویزات کو پہچاننے کے عمل سے اتنا مختلف نہیں ہے، مثال کے طور پر، عددی ڈیٹا کے بہت سے صفحات بنانے والی میزیں۔ جی ہاں، اصولی طور پر ایسا کرنا ممکن ہے، لیکن یہ سب سے بہترین طریقہ نہیں ہے، سوائے آخری حربے کے، جب کہ کوئی اور آپشن نہ ہو۔ ایک معقول حل یہ ہے کہ اصل ڈیٹا کی ایک ڈیجیٹل کاپی تلاش کی جائے جو کسی دستاویز کے ماڈل میں سرایت نہ ہو جو ڈیٹا کو اس کی مخصوص متنی نمائندگی کے ساتھ جوڑتا ہو۔
یہ کہا جا رہا ہے، یہ مجھے بالکل حیران نہیں کرتا کہ XML کاروبار میں مقبول ہے. اس کی وجہ قطعی طور پر یہ ہے کہ دستاویز کی شکل (کاغذ پر) کاروبار کے لیے قابل فہم اور مانوس ہے، اور وہ ایک مانوس اور قابل فہم ماڈل کا استعمال جاری رکھنا چاہتے ہیں۔ اسی وجہ سے، کاروبار بھی اکثر مشین سے پڑھنے کے قابل فارمیٹس کی بجائے پی ڈی ایف دستاویزات کا استعمال کرتے ہیں - کیونکہ وہ اب بھی ایک مخصوص جسمانی سائز کے ساتھ پرنٹ شدہ صفحہ کے تصور سے منسلک ہیں۔ یہ ان دستاویزات پر بھی لاگو ہوتا ہے جن کے پرنٹ ہونے کا امکان نہیں ہے (مثال کے طور پر، رجسٹری دستاویزات کی 8000 صفحات پر مشتمل پی ڈی ایف)۔ اس نقطہ نظر سے، کاروبار میں XML کا استعمال بنیادی طور پر skeuomorphism کا مظہر ہے۔ لوگ محدود سائز کے پرنٹ شدہ صفحہ کے استعاراتی خیال کو سمجھتے ہیں، اور وہ سمجھتے ہیں کہ پرنٹ شدہ دستاویزات کی بنیاد پر کاروباری عمل کیسے بنایا جائے۔ اگر یہ آپ کا گائیڈ ہے، تو وہ دستاویزات جو جسمانی سائز کی حدود کے بغیر ہیں جو مشین کے ذریعے پڑھنے کے قابل ہیں — XML دستاویزات — ایک مانوس اور آرام دہ دستاویز کے ہم منصب ہوتے ہوئے جدت کی نمائندگی کرتی ہیں۔ یہ انہیں ڈیٹا پیش کرنے کا ایک غلط اور حد سے زیادہ سکیومورفک طریقہ رہنے سے نہیں روکتا۔
آج تک، صرف XML اسکیموں کے بارے میں میں جانتا ہوں کہ میں صحیح معنوں میں فارمیٹ کا درست استعمال کہہ سکتا ہوں وہ ہیں XHTML اور DocBook۔
ماخذ: www.habr.com