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 که تا به حال دیده ام، فرمت فایل پیکربندی تامین خودکار را برای تلفن های تلفن IP Polycom دریافت می کند. چنین فایل هایی نیاز به دانلود فایل های درخواست XML از طریق TFTP دارند که ... به طور کلی، در اینجا گزیده ای از یکی از این فایل ها آورده شده است:

<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 به‌جای فرمت‌های قابل خواندن توسط ماشین استفاده می‌کنند - زیرا آنها هنوز به مفهوم یک صفحه چاپ شده با اندازه فیزیکی خاص مرتبط هستند. این حتی برای اسنادی که بعید است هرگز چاپ شوند نیز صدق می کند (به عنوان مثال، یک PDF 8000 صفحه ای از اسناد رجیستری). از این دیدگاه، استفاده از XML در تجارت اساساً تجلی اسکئومورفیسم است. مردم ایده استعاری یک صفحه چاپ شده با اندازه محدود را درک می کنند و می دانند که چگونه فرآیندهای تجاری را بر اساس اسناد چاپ شده ایجاد کنند. اگر راهنمای شما این است، اسناد بدون محدودیت اندازه فیزیکی که توسط ماشین قابل خواندن هستند - اسناد XML - نشان دهنده نوآوری هستند در حالی که همتای سند آشنا و راحت هستند. این مانع از آن نمی شود که روشی نادرست و بیش از حد اسکیومورفیک برای ارائه داده باقی بمانند.

تا به امروز، تنها طرح‌واره‌های XML که من می‌شناسم و می‌توانم استفاده معتبر از این قالب را بدانم XHTML و DocBook هستند.

منبع: www.habr.com