প্রকাশিত: ২৯ অক্টোবর, ২০২৫
ক্রোম ব্রাউজার থেকে XSLT-কে অপ্রচলিত ঘোষণা করে সরিয়ে ফেলার পরিকল্পনা করছে। ২০২৬ সালের শেষের দিকে এটি সরিয়ে ফেলার আগে, আপনি কীভাবে আপনার কোড স্থানান্তর করতে পারেন, তা এই নথিতে বিস্তারিতভাবে বর্ণনা করা হয়েছে।
ক্রোমিয়াম আনুষ্ঠানিকভাবে XSLT-কে অপ্রচলিত ঘোষণা করেছে, যার মধ্যে XSLTProcessor জাভাস্ক্রিপ্ট এপিআই এবং XSLT প্রসেসিং নির্দেশনা অন্তর্ভুক্ত। আমরা সংস্করণ ১৫৮ (১৭ নভেম্বর, ২০২৬) থেকে এর সমর্থন তুলে নেওয়ার পরিকল্পনা করছি। ফায়ারফক্স এবং ওয়েবকিট প্রকল্পগুলোও তাদের ব্রাউজার ইঞ্জিন থেকে XSLT সরিয়ে ফেলার পরিকল্পনা জানিয়েছে। এই নথিতে কিছু ইতিহাস ও প্রেক্ষাপট তুলে ধরা হয়েছে, ক্রোমকে আরও নিরাপদ করার জন্য আমরা কীভাবে XSLT সরিয়ে ফেলছি তা ব্যাখ্যা করা হয়েছে, এবং ব্রাউজার থেকে এই বৈশিষ্ট্যগুলো সরিয়ে ফেলার আগে মাইগ্রেট করার একটি পথ দেখানো হয়েছে। সর্বশেষ আপডেটের জন্য, ক্রোম প্ল্যাটফর্ম স্ট্যাটাস এন্ট্রিটিও দেখুন।
কী সরানো হচ্ছে?
ব্রাউজারে দুটি এপিআই আছে যেগুলো XSLT প্রয়োগ করে, এবং উভয়ই সরিয়ে ফেলা হচ্ছে:
- XSLTProcessor ক্লাস (উদাহরণস্বরূপ,
new XSLTProcessor())। - XSLT প্রসেসিং নির্দেশনা (উদাহরণস্বরূপ,
<?xml-stylesheet type="text/xsl" ... ?>)।
ক্রোমের জন্য টাইমলাইন
ক্রোমের নিম্নলিখিত পরিকল্পনা রয়েছে:
- ক্রোম ১৪২ (২৮ অক্টোবর, ২০২৫): ক্রোমে আগাম সতর্কীকরণ কনসোল বার্তা যোগ করা হয়েছে।
- ক্রোম ১৪৩ (২ ডিসেম্বর, ২০২৫): এপিআই-এর আনুষ্ঠানিক বাতিলকরণ - কনসোল এবং লাইটহাউসে বাতিলকরণের সতর্কীকরণ বার্তা প্রদর্শিত হতে শুরু করবে।
- ক্রোম ১৪৫ (২ ডিসেম্বর, ২০২৫ ক্যানারি ): আগাম সতর্কতা হিসেবে, ক্যানারি, ডেভ এবং বিটা রিলিজগুলোতে ডিফল্টরূপে XSLT নিষ্ক্রিয় করা শুরু হবে।
- ক্রোম ১৪৬ (১০ মার্চ, ২০২৬): এন্টারপ্রাইজ পলিসি (ইপি) পরীক্ষার জন্য চালু হচ্ছে। এটি প্রতিষ্ঠানগুলোকে আগেভাগেই XSLT নিষ্ক্রিয় করার পরীক্ষা করার সুযোগ দেবে এবং অপসারণের তারিখের পরেও ফিচারগুলো ব্যবহার চালিয়ে যাওয়ার অনুমতি দেবে।
- ক্রোম ১৫২ (২৫শে আগস্ট, ২০২৬): পরীক্ষার জন্য অরিজিন ট্রায়াল (OT) চালু হচ্ছে। এর ফলে সাইটগুলো অপসারণের তারিখের পরেও ফিচারগুলো ব্যবহার করা চালিয়ে যেতে পারবে।
- ক্রোম ১৫৮ (১৭ নভেম্বর, ২০২৬): অরিজিন ট্রায়াল এবং এন্টারপ্রাইজ পলিসি অংশগ্রহণকারী ব্যতীত অন্য সকল ব্যবহারকারীর জন্য স্টেবল রিলিজগুলোতে XSLT কাজ করা বন্ধ করে দেবে।
- ক্রোম ১৭৬ (আগস্ট ১৭, ২০২৭): অরিজিন ট্রায়াল এবং এন্টারপ্রাইজ পলিসি কাজ করা বন্ধ করে দেবে। সকল ব্যবহারকারীর জন্য XSLT নিষ্ক্রিয় করা হবে।
XSLT কী?
XSLT, বা এক্সটেনসিবল স্টাইলশিট ল্যাঙ্গুয়েজ ট্রান্সফরমেশনস, হলো একটি ভাষা যা XML ডকুমেন্টকে সাধারণত HTML-এর মতো অন্যান্য ফরম্যাটে রূপান্তর করতে ব্যবহৃত হয়। এই রূপান্তরের নিয়মাবলী নির্ধারণ করতে এটি একটি XSLT স্টাইলশিট ফাইল এবং ইনপুট হিসেবে ব্যবহৃত ডেটা ধারণকারী একটি XML ফাইল ব্যবহার করে।
ব্রাউজারে, যখন কোনো XML ফাইল আসে যা একটি XSLT স্টাইলশীটের সাথে লিঙ্ক করা থাকে, তখন ব্রাউজার সেই স্টাইলশীটের নিয়মগুলো ব্যবহার করে কাঁচা XML ডেটাকে পুনর্বিন্যাস, ফরম্যাট এবং রূপান্তর করে একটি কাঠামোবদ্ধ পৃষ্ঠায় (প্রায়শই HTML) পরিণত করে, যা ব্যবহারকারীর জন্য রেন্ডার করা যায়।
উদাহরণস্বরূপ, একটি XSLT স্টাইলশীট নিম্নলিখিত XML ইনপুট নিতে পারে:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
<message>
Hello World.
</message>
</page>
এবং এই XSL স্টাইলশীট:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html"/>
<xsl:template match="/page/message">
<body>
<p>Message: <xsl:value-of select="."/></p>
</body>
</xsl:template>
</xsl:stylesheet>
এবং ব্রাউজারে প্রদর্শনের জন্য সেগুলোকে এই HTML-এ রূপান্তর করুন: HTML
<body>
<p>Message: Hello World.</p>
</body>
পূর্ববর্তী উদাহরণে দেখানো XSL প্রসেসিং নির্দেশাবলী ছাড়াও, XSLTProcessor জাভাস্ক্রিপ্ট এপিআই (API) রয়েছে, যা স্থানীয় XSLT স্টাইলশীট ব্যবহার করে স্থানীয় XML ডকুমেন্ট প্রসেস করার জন্য ব্যবহার করা যেতে পারে।
XSLT-এর ইতিহাস
১৯৯৯ সালের ১৬ই নভেম্বর ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম (W3C) কর্তৃক XSLT-কে XML ডকুমেন্টকে অন্যান্য ফরম্যাটে, বিশেষত ওয়েব ব্রাউজারে প্রদর্শনের জন্য HTML-এ রূপান্তর করার একটি ভাষা হিসেবে সুপারিশ করা হয়েছিল। আনুষ্ঠানিক ১.০ সংস্করণের সুপারিশের আগে, মাইক্রোসফট ১৯৯৯ সালের মার্চ মাসে প্রকাশিত ইন্টারনেট এক্সপ্লোরার ৫.০- তে W3C-এর একটি ওয়ার্কিং ড্রাফটের উপর ভিত্তি করে একটি নিজস্ব ইমপ্লিমেন্টেশন অন্তর্ভুক্ত করে একটি প্রাথমিক উদ্যোগ গ্রহণ করে। আনুষ্ঠানিক স্ট্যান্ডার্ডটি অনুসরণ করে, মোজিলা ২০০০ সালের শেষের দিকে নেটস্কেপ ৬- এ নেটিভ XSLT ১.০ সাপোর্ট বাস্তবায়ন করে। সাফারি, অপেরা এবং পরবর্তীতে ক্রোম সহ অন্যান্য প্রধান ব্রাউজারগুলোও নেটিভ XSLT ১.০ প্রসেসর অন্তর্ভুক্ত করে, যা ২০০০-এর দশকের শুরুতে ক্লায়েন্ট-সাইড XML-টু-HTML রূপান্তরকে একটি কার্যকর ওয়েব প্রযুক্তিতে পরিণত করে।
XSLT ভাষাটির বিবর্তন অব্যাহত ছিল, যার প্রমাণ মেলে ২০০৭ সালে XSLT 2.0 এবং ২০১৭ সালে XSLT 3.0 প্রকাশের মাধ্যমে, যা রেগুলার এক্সপ্রেশন, উন্নত ডেটা টাইপ এবং JSON প্রসেস করার ক্ষমতার মতো শক্তিশালী বৈশিষ্ট্য নিয়ে আসে। তবে, ব্রাউজার সাপোর্ট স্থবির হয়ে পড়ে। বর্তমানে, সমস্ত প্রধান ওয়েব ব্রাউজার ইঞ্জিন শুধুমাত্র ১৯৯৯ সালের মূল XSLT 1.0-এর জন্য নেটিভ সাপোর্ট প্রদান করে। এই অগ্রগতির অভাব, ওয়্যার ফরম্যাট হিসেবে JSON-এর ব্যবহার বৃদ্ধি এবং জাভাস্ক্রিপ্ট লাইব্রেরি ও ফ্রেমওয়ার্ক (যেমন jQuery, React, এবং Vue.js) যা আরও নমনীয় ও শক্তিশালী DOM ম্যানিপুলেশন এবং টেমপ্লেটিং সুবিধা দেয়, এই সবকিছুর ফলে ক্লায়েন্ট-সাইড XSLT-এর ব্যবহার উল্লেখযোগ্যভাবে হ্রাস পেয়েছে। ওয়েব ব্রাউজারের মধ্যে এর ভূমিকা মূলত এই জাভাস্ক্রিপ্ট-ভিত্তিক প্রযুক্তিগুলো দ্বারা প্রতিস্থাপিত হয়েছে।
XSLT কেন অপসারণ করা প্রয়োজন?
ওয়েব ব্রাউজারগুলিতে XSLT 1.0-এর ক্রমাগত অন্তর্ভুক্তি একটি গুরুতর এবং অপ্রয়োজনীয় নিরাপত্তা ঝুঁকি তৈরি করে। এই রূপান্তরগুলি প্রক্রিয়াকারী অন্তর্নিহিত লাইব্রেরিগুলি, যেমন libxslt (ক্রোমিয়াম ব্রাউজারগুলিতে ব্যবহৃত), জটিল এবং পুরোনো C/C++ কোডবেস। এই ধরনের কোড বাফার ওভারফ্লো-এর মতো মেমরি নিরাপত্তা দুর্বলতার জন্য কুখ্যাতভাবে সংবেদনশীল, যা যথেচ্ছ কোড এক্সিকিউশনের কারণ হতে পারে। উদাহরণস্বরূপ, নিরাপত্তা নিরীক্ষা এবং বাগ ট্র্যাকারগুলি এই পার্সারগুলিতে বারবার উচ্চ-গুরুত্বপূর্ণ দুর্বলতা চিহ্নিত করেছে (যেমন, CVE-2025-7425 এবং CVE-2022-22834 , উভয়ই libxslt-তে)। যেহেতু ক্লায়েন্ট-সাইড XSLT এখন একটি বিশেষায়িত এবং কদাচিৎ ব্যবহৃত বৈশিষ্ট্য, তাই এই লাইব্রেরিগুলি মূল জাভাস্ক্রিপ্ট ইঞ্জিনগুলির তুলনায় অনেক কম রক্ষণাবেক্ষণ এবং নিরাপত্তা নিরীক্ষার সম্মুখীন হয়, তবুও এগুলি অবিশ্বস্ত ওয়েব কন্টেন্ট প্রক্রিয়াকরণের জন্য একটি সরাসরি এবং শক্তিশালী আক্রমণের ক্ষেত্র হিসেবে কাজ করে। প্রকৃতপক্ষে, XSLT সাম্প্রতিক বেশ কয়েকটি বহুল আলোচিত নিরাপত্তা এক্সপ্লয়েটের উৎস, যা ব্রাউজার ব্যবহারকারীদের ক্রমাগত ঝুঁকিতে ফেলছে। এই ভঙ্গুর ও পুরোনো কার্যকারিতাটি বজায় রাখার নিরাপত্তা ঝুঁকি, এর সীমিত আধুনিক উপযোগিতাকে বহুগুণে ছাড়িয়ে যায়।
তাছাড়া, ক্লায়েন্ট-সাইড XSLT-এর মূল উদ্দেশ্য—ডেটাকে রেন্ডারযোগ্য HTML-এ রূপান্তর করা—এখন আরও নিরাপদ, ব্যবহার-বান্ধব এবং ভালোভাবে রক্ষণাবেক্ষণ করা জাভাস্ক্রিপ্ট এপিআই দ্বারা প্রতিস্থাপিত হয়েছে। আধুনিক ওয়েব ডেভেলপমেন্ট ডেটা (সাধারণত JSON) পুনরুদ্ধার করার জন্য Fetch API এবং ব্রাউজারের সুরক্ষিত জাভাস্ক্রিপ্ট স্যান্ডবক্সের মধ্যে XML বা HTML স্ট্রিংগুলোকে নিরাপদে পার্স করে একটি DOM কাঠামোতে রূপান্তর করার জন্য DOMParser API-এর মতো বিষয়গুলোর উপর নির্ভর করে। এরপর React, Vue, এবং Svelte-এর মতো ফ্রেমওয়ার্কগুলো এই ডেটার রেন্ডারিং দক্ষতার সাথে এবং নিরাপদে পরিচালনা করে। এই আধুনিক টুলচেইনটি সক্রিয়ভাবে উন্নত করা হচ্ছে, জাভাস্ক্রিপ্ট ইঞ্জিনগুলোতে করা ব্যাপক নিরাপত্তা বিনিয়োগ থেকে এটি সুবিধা পাচ্ছে, এবং বর্তমানে প্রায় সকল ওয়েব ডেভেলপার এটিই ব্যবহার করেন। প্রকৃতপক্ষে, বর্তমানে মাত্র ০.০২% ওয়েব পেজ লোডে XSLT ব্যবহৃত হয়, যার মধ্যে ০.০০১% -এরও কম পেজ XSLT প্রসেসিং নির্দেশাবলী ব্যবহার করে।
এটি শুধু ক্রোম বা ক্রোমিয়ামের একার পদক্ষেপ নয়: অন্য দুটি প্রধান ব্রাউজার ইঞ্জিনও ওয়েব প্ল্যাটফর্ম থেকে XSLT অপসারণ সমর্থন করে: ওয়েবকিট ও গেকো ।
এইসব কারণে, XSLT-কে অপ্রচলিত ঘোষণা করা এবং অপসারণ করা সকল ব্যবহারকারীর জন্য ব্রাউজারের আক্রমণের ঝুঁকি কমায়, ওয়েব প্ল্যাটফর্মকে সরল করে, এবং ডেভেলপারদের সক্ষমতার কোনো বাস্তব ক্ষতি ছাড়াই প্রকৌশলগত সংস্থানগুলোকে আধুনিক ওয়েবের চালিকাশক্তি প্রযুক্তিগুলোর সুরক্ষায় মনোনিবেশ করার সুযোগ করে দেয়।
এক্সএমএল পার্সিং নিরাপত্তা উন্নত করা
libxslt-এর গুরুতর নিরাপত্তা সমস্যার মতোই, সম্প্রতি libxml2-এর বিরুদ্ধেও গুরুতর নিরাপত্তা সমস্যার কথা জানা গেছে, যা ক্রোমিয়ামে XML-এর পার্সিং, সিরিয়ালাইজেশন এবং সুগঠন পরীক্ষা করার জন্য ব্যবহৃত হয়। ক্রোমিয়ামে XML পার্সিং সংক্রান্ত ভবিষ্যৎ নিরাপত্তা সমস্যাগুলো মোকাবেলা করার জন্য আমরা libxml2-এর ব্যবহার পর্যায়ক্রমে বন্ধ করে দেওয়ার এবং এর পরিবর্তে রাস্ট (Rust)-এ লেখা একটি মেমরি-সেফ XML পার্সিং লাইব্রেরি ব্যবহার করার পরিকল্পনা করছি। গুরুত্বপূর্ণ বিষয় হলো, আমরা ব্রাউজার থেকে XML সরাচ্ছি না; এখানে শুধুমাত্র XSLT সরানোর বিষয়টি বিবেচনা করা হচ্ছে। আমরা নিশ্চিত করতে চাই যে libxml2 প্রতিস্থাপনের বিষয়টি ওয়েব ডেভেলপারদের কাছে সম্পূর্ণ স্বচ্ছ থাকবে।
XML + CSS সরানো হচ্ছে না
XSLT ( <?xml-stylesheet type="text/xsl" ... ?> ) এর অপ্রচলিত হয়ে যাওয়া এবং <?xml-stylesheet ... ?> প্রসেসিং ইন্সট্রাকশনটির মধ্যে পার্থক্য করা গুরুত্বপূর্ণ, কারণ CSS-এর সাথে ব্যবহৃত হলে এটি এখনও সমর্থিত। আপনি এখনও type="text/css" এর সাথে প্রসেসিং ইন্সট্রাকশনটি ব্যবহার করে আপনার মূল ডেটাতে সাধারণ লেআউট এবং ডিজাইনের নিয়ম প্রয়োগ করতে পারেন, ঠিক যেমনটা আপনি HTML-এর ক্ষেত্রে করেন। উদাহরণস্বরূপ:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
<item>Content here</item>
</root>
কীভাবে স্থানান্তর করবেন
অভিবাসনের জন্য কয়েকটি বিকল্প পথ রয়েছে।
JSON
যেসব সাইট সম্পূর্ণরূপে XML এবং XSL-এর উপর ভিত্তি করে তৈরি, সেগুলোর ক্ষেত্রে এই রূপান্তরের জন্য কোনো একটি সর্বজনীন উপায় নেই। মাইগ্রেশনের বিকল্পগুলোর মধ্যে রয়েছে XSLT প্রসেসিং পাইপলাইনকে সার্ভার সাইডে নিয়ে যাওয়া এবং রেন্ডার করা HTML ক্লায়েন্টের কাছে পাঠিয়ে দেওয়া, অথবা সার্ভার-সাইড XML API এন্ডপয়েন্টগুলোকে JSON- এ মাইগ্রেট করা এবং জাভাস্ক্রিপ্ট ব্যবহার করে ক্লায়েন্ট-সাইড রেন্ডারিংয়ের মাধ্যমে JSON-কে HTML DOM ও CSS-এ রূপান্তর করা।
জাভাস্ক্রিপ্টে ক্লায়েন্ট-সাইড XSLT
কয়েকটি ক্লায়েন্ট-সাইড (জাভাস্ক্রিপ্ট-ভিত্তিক) XSLT লাইব্রেরি উপলব্ধ আছে, কিন্তু এদের মধ্যে সবচেয়ে বড়টি তৈরি করেছে স্যাক্সোনিকা ( স্যাক্সোনিকার বিস্তারিত ডকুমেন্টেশন দেখুন)। এর ইমপ্লিমেন্টেশনটি ওয়েব ব্রাউজারে থাকা XSLT 1.0 ইমপ্লিমেন্টেশনকে অনেক ছাড়িয়ে গেছে; এটি সর্বশেষ v3.0 স্ট্যান্ডার্ডের জন্য সম্পূর্ণ সাপোর্ট প্রদান করে এবং পরবর্তীতে নির্মাণাধীন v4.0 স্ট্যান্ডার্ডকেও সাপোর্ট করবে।
পলিফিল
এমন একটি পলিফিল রয়েছে যা ওয়েব ব্রাউজারের XSLT 1.0 ইমপ্লিমেন্টেশনের উপর নির্ভরশীল বিদ্যমান কোডকে ব্রাউজারের নেটিভ XSLT ফিচার ব্যবহার না করেই সচল রাখার চেষ্টা করে। পলিফিলটি গিটহাবে অবস্থিত ।
এই পলিফিলটিতে XSLTProcessor ক্লাসের জন্য একটি কার্যকরী WASM-ভিত্তিক পলিফিল করা প্রতিস্থাপন রয়েছে, ফলে বিদ্যমান জাভাস্ক্রিপ্ট কোড অপরিবর্তিতভাবে কাজ করা চালিয়ে যেতে পারে:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
এই পলিফিলটি XSLT প্রসেসিং নির্দেশাবলী ব্যবহারকারী XML ডকুমেন্টগুলি সহজে প্রতিস্থাপন করার জন্য একটি স্বয়ংক্রিয় ইউটিলিটি ফাংশনও প্রদান করে:
এরকম একটি আসল demo.xml ফাইলের জন্য:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
পলিফিলটি চালু করতে এবং উল্লেখিত XSLT স্টাইলশীট দিয়ে ডকুমেন্টটি রূপান্তর করতে একটি লাইন যোগ করা যেতে পারে:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
xmlns="http://www.w3.org/1999/xhtml"></script>
...content...
এক্ষেত্রে, নতুন <script> এলিমেন্টটি পলিফিল লোড করে, যা XML ডকুমেন্টের ধরন ও XSLT প্রসেসিং নির্দেশনা শনাক্ত করে এবং স্বচ্ছভাবে তা লোড করে ডকুমেন্টটিকে প্রতিস্থাপন করে।
সম্প্রসারণ
একটি ক্রোম এক্সটেনশনও রয়েছে যা সমর্থিত ব্রাউজারগুলিতে যোগ করা যেতে পারে। এটি সেই সমস্ত র XML পেজে একই XSLT পলিফিল প্রয়োগ করবে যেগুলিতে XSLT প্রসেসিং নির্দেশাবলী বা XSLTProcessor-এর কল রয়েছে। যেসব অ্যাপ্লিকেশনের ক্ষেত্রে কার্যকারিতা বজায় রাখার জন্য সোর্স XML বা XSLT পরিবর্তন করা যায় না, সেখানে এটি ব্যবহার করা যেতে পারে।
বিশেষ করে, যখন XSLT নিষ্ক্রিয় করা হয়, তখন Chrome এখন একটি সতর্কীকরণ ব্যানার দেখায় যা সরাসরি একটি এক্সটেনশন অনুসন্ধান পৃষ্ঠায় নিয়ে যায়, যাতে ব্যবহারকারীরা একটি এক্সটেনশন খুঁজে পেতে পারেন:
নির্দিষ্ট ব্যবহারের ক্ষেত্র
এইচটিএমএল স্ট্যান্ডার্ডের আলোচনায় বেশ কিছু সুনির্দিষ্ট ব্যবহারের ক্ষেত্র চিহ্নিত করা হয়েছিল। এই বিভাগে সেগুলোর প্রত্যেকটি নিয়ে বিশেষভাবে আলোচনা করা হয়েছে, যাতে বর্তমানে XSLT ব্যবহার করে এক্সএমএল রিসোর্স প্রকাশকারী ডেভেলপারদের জন্য ভবিষ্যৎ কর্মপন্থা সুপারিশ করা যায়।
আরএসএস এবং অ্যাটম ফিড
বিদ্যমান অনেক RSS বা Atom ফিডে, সরাসরি ব্রাউজারে দেখার সময় কাঁচা XML ফিডকে পাঠযোগ্য করে তোলার জন্য XSLT ব্যবহার করা হয়। এর প্রধান ব্যবহার হলো, যখন কোনো ব্যবহারকারী ভুলবশত কোনো সাইটের RSS ফিড লিঙ্কে ক্লিক করেন, তখন সেই লিঙ্কটি তাদের RSS রিডারে পেস্ট করার পরিবর্তে, তারা সরাসরি কাঁচা XML-এর বদলে একটি ফরম্যাট করা HTML প্রতিক্রিয়া পান যা তারা পড়তে পারেন।
এই ব্যবহারের ক্ষেত্রে দুটি পথ খোলা আছে। এটি করার "প্রমিত" HTML পদ্ধতি হলো, একটি (HTML-ভিত্তিক) সাইটে <link rel="alternate" type="application/rss+xml"> যোগ করা, সুস্পষ্ট (ব্যবহারকারীর কাছে দৃশ্যমান) <a href="something.xml"> যোগ করার পরিবর্তে, কারণ ব্যবহারকারীরা ভুলবশত এতে ক্লিক করে ফেলতে পারেন। এই সমাধানটি RSS রিডারদের ফিডটি খুঁজে পেতে সাহায্য করে যদি কোনো ব্যবহারকারী শুধু ওয়েবসাইটের URL পেস্ট করেন, কিন্তু এটি সাধারণ ব্যবহারকারীদেরও একটি XML রিসোর্সের লিঙ্ক দেখে বিভ্রান্ত না হয়ে সাধারণ HTML কন্টেন্ট দেখার সুযোগ দেয়। এটি ওয়েবের সেই সাধারণ নীতিও অনুসরণ করে যে HTML মানুষের জন্য এবং XML মেশিনের জন্য। অবশ্যই, এটি সেই সমস্যার সমাধান করে না যেখানে কোনো ব্যবহারকারীর কাছে কোথা থেকে একটি RSS লিঙ্ক থাকে এবং তিনি সেটি তার ওয়েব ব্রাউজারে (RSS রিডারের পরিবর্তে) পেস্ট করেন।
যখন সেই সমাধানটি কাঙ্ক্ষিত নয়, তখন পলিফিলটি আরেকটি পথ দেখায়। পূর্বে যেমন উল্লেখ করা হয়েছে, RSS/Atom XML ফিডকে একটি লাইন দিয়ে বর্ধিত করা যেতে পারে, <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script> , যা HTML-এ XSLT-ভিত্তিক রূপান্তরের বিদ্যমান আচরণ বজায় রাখবে। এটি RSS রিডারের XML পার্সিং চালিয়ে যাওয়ার ক্ষমতাকে প্রভাবিত করবে না, কারণ <script> ট্যাগটি রুট এলিমেন্টের একটি সরাসরি চাইল্ড।
এমবেডেড ডিভাইসের জন্য এপিআই আউটপুট
কিছু বাণিজ্যিক এমবেডেড ডিভাইস লোকাল নেটওয়ার্কে থাকা ব্যবহারকারীদের ব্যবহারের জন্য XML ডেটা পরিমাপ করে বা অন্য কোনো উপায়ে তৈরি করে। এই ডিভাইসগুলোর মধ্যে কয়েকটি একটিমাত্র XML ডেটা ফিড তৈরি করে, যা XSLT ব্যবহার করে ডেটাটিকে মানুষের পাঠযোগ্য HTML ফরম্যাটে রূপান্তরিত করে। এর ফলে ডিভাইসে বা ব্রাউজারে কোনো অতিরিক্ত কোডের প্রয়োজন ছাড়াই API-টি সরাসরি ব্রাউজারে দেখা যায়।
যেহেতু এটি একটি অ্যাপ্লিকেশন-নির্দিষ্ট ব্যবহারের ক্ষেত্র, তাই সমাধানের ধরন ভিন্ন হতে পারে। যেসব অ্যাপ্লিকেশনের ক্ষেত্রে এমবেডেড ডিভাইসের সোর্স কোড আপডেট করা যায়, সেখানে পূর্বে বর্ণিত যেকোনো বিকল্প (JSON, Polyfill) কাজ করতে পারে। তবে, বিশেষত, বিভিন্ন কারণে এই ধরনের অনেক ডিভাইস আপডেট করা কঠিন বা অসম্ভব। সেক্ষেত্রে, এক্সটেনশনটিই সম্ভবত সেরা বিকল্প, কারণ এটি ক্লায়েন্ট ব্রাউজারগুলোকে ডিভাইসটি পরিবর্তন না করেই ঠিক আগের মতোই ডেটা পড়া চালিয়ে যেতে দেয়।
ওয়েবসাইটের জন্য অলস টেমপ্লেটিং
ওয়েব ডেভেলপাররা কখনও কখনও ক্লায়েন্ট সাইডে সিমান্টিক মার্কআপের উপর প্রেজেন্টেশন মার্কআপ প্রয়োগ করতে XSLT ব্যবহার করেন, যা জাভাস্ক্রিপ্ট ইকোসিস্টেম থেকে আলাদা একটি লেজি টেমপ্লেটিং ল্যাঙ্গুয়েজ হিসেবে কাজ করে।
এই সাধারণ সমস্যাটির দুটি সমাধান আছে। এইভাবে তৈরি করা কোনো বিদ্যমান সাইটের জন্য, সবচেয়ে সহজ সমাধান সম্ভবত হলো বিদ্যমান কার্যকারিতা বজায় রাখতে শুধু পলিফিল যোগ করা। অথবা, সার্ভার সাইডে XSLT রূপান্তরটি সম্পাদন করে, সরাসরি XML-এর পরিবর্তে প্রাপ্ত HTML ক্লায়েন্টকে পরিবেশন করা যেতে পারে। এই ধরনের প্রোপার্টিগুলোর জন্য দীর্ঘমেয়াদী সমাধান হলো আরও আধুনিক জাভাস্ক্রিপ্ট বা JSON-ভিত্তিক ফ্রেমওয়ার্কে স্থানান্তরিত হওয়া।
এই XSLT বাতিলকরণ সম্পর্কিত কোনো নির্দিষ্ট সমস্যা Chrome-এ পেলে, এখানে একটি বাগ রিপোর্ট করুন ।
XSLT-এর ব্যবহার কীভাবে শনাক্ত করা যায়
সাধারণত, আপনার কোডবেসে XSLT-এর মতো অপ্রচলিত ফিচারগুলো কয়েকটি উপায়ে শনাক্ত করা যায়। এই অংশে সেগুলোর মধ্যে দুটি তুলে ধরা হলো।
রিপোর্টিং এপিআই
রিপোর্টিং এপিআই হলো ওয়েব অ্যাপ্লিকেশনগুলোর জন্য একটি জেনেরিক রিপোর্টিং ব্যবস্থা, যা বিভিন্ন প্ল্যাটফর্মের ফিচার ও অবস্থা, এমনকি ফিচারের অবলুপ্তি সম্পর্কেও রিপোর্ট করতে ব্যবহৃত হয়। XSLT-এর অবলুপ্তি সম্পর্কে রিপোর্ট করার জন্য এটিকে সেট আপ করতে, এই ধরনের একটি কোড স্নিপেট ব্যবহার করা যেতে পারে:
new ReportingObserver((reports, observer) => {
reports.forEach((report) => {
if (report.body.id === "XSLT") {
// XSLT usage was detected - report it back here.
}
});
}, {types: ["deprecation"],buffered: true}).observe();
CodePen-এ এই কোডটির প্রয়োগ দেখুন ।
এন্টারপ্রাইজ লিগ্যাসি টেকনোলজি রিপোর্ট
কোনো প্রতিষ্ঠানের অ্যাডমিনরা অপ্রচলিত ফিচারের ব্যবহার স্বয়ংক্রিয়ভাবে সংগ্রহ করতে এবং ব্যবহারকারী-বান্ধব উপায়ে তা রিপোর্ট করার জন্য লিগ্যাসি টেকনোলজি রিপোর্ট ব্যবহার করতে পারেন। এই ফিচারটি কীভাবে চালু করতে হয় সে সম্পর্কে আরও তথ্যের জন্য এই গুগল সাপোর্ট আর্টিকেলটি দেখুন।