প্রকাশিত: ২৯ অক্টোবর, ২০২৫
Chrome ব্রাউজার থেকে XSLT বাতিল করে সরিয়ে দিতে চায়। এই ডকুমেন্ট থেকে আপনি জানতে পারবেন যে ২০২৬ সালের শেষের দিকে কোড সরিয়ে দেওয়ার আগে কীভাবে তা মাইগ্রেট করবেন।
Chromium আনুষ্ঠানিকভাবে XSLT-কে বাতিল করেছে, যার মধ্যে XSLTProcessor জাভাস্ক্রিপ্ট API এবং XSLT প্রসেসিং নির্দেশাবলী অন্তর্ভুক্ত। আমরা ভার্সন ১৫৮ (১৭ নভেম্বর, ২০২৬) থেকে সহায়তা সরিয়ে দেওয়ার সিদ্ধান্ত নিয়েছি। Firefox এবং WebKit প্রোজেক্টও তাদের ব্রাউজার ইঞ্জিন থেকে XSLT সরানোর পরিকল্পনা করেছে। এই ডকুমেন্ট থেকে কিছু ইতিহাস ও প্রসঙ্গ জানা যায়, Chrome-কে আরও নিরাপদ করতে আমরা কীভাবে XSLT সরিয়ে দিচ্ছি তা ব্যাখ্যা করে এবং ব্রাউজার থেকে এইসব ফিচার সরিয়ে দেওয়ার আগে মাইগ্রেট করার পথ দেখায়। লেটেস্ট আপডেটের জন্য, Chrome প্ল্যাটফর্ম স্ট্যাটাস এন্ট্রি দেখুন।
কী সরানো হচ্ছে?
ব্রাউজারে দুটি API আছে যা XSLT প্রয়োগ করে এবং দুটিই সরিয়ে দেওয়া হচ্ছে:
- XSLTProcessor
ক্লাস (যেমন,
new XSLTProcessor())। - XSLT প্রসেসিং
নির্দেশাবলী
(যেমন,
<?xml-stylesheet type="text/xsl" ... ?>)।
Chrome-এর জন্য টাইমলাইন
Chrome-এর নিম্নলিখিত প্ল্যান আছে:
- Chrome 142 (২৮ অক্টোবর, ২০২৫): Chrome-এ আগাম সতর্কতা কনসোল মেসেজ যোগ করা হয়েছে।
- Chrome 143 (২ ডিসেম্বর, ২০২৫): API-এর অফিসিয়াল ডেপ্রিকেশন - ডেপ্রিকেশন সম্পর্কিত সতর্কতামূলক মেসেজ কনসোল ও লাইটহাউসে দেখানো শুরু হবে।
- Chrome 145 (২ ডিসেম্বর, ২০২৫ Canary): Canary, Dev ও Beta রিলিজ, আগাম সতর্কতা হিসেবে, ডিফল্ট হিসেবে XSLT বন্ধ করা শুরু করে।
- Chrome 146 (১০ মার্চ, ২০২৬): এন্টারপ্রাইজ নীতি (EP) পরীক্ষার জন্য লাইভ হবে। এর ফলে, এন্টারপ্রাইজগুলি XSLT বন্ধ করার বিষয়টি আগে থেকেই পরীক্ষা করতে পারবে এবং সরানোর তারিখের পরেও ফিচারগুলি ব্যবহার করা চালিয়ে যেতে পারবে।
- Chrome 152 (২৫ আগস্ট, ২০২৬): পরীক্ষার জন্য অরিজিন ট্রায়াল (OT) লাইভ হবে। এর ফলে সাইটগুলি সরানোর তারিখের পরেও ফিচার ব্যবহার করা চালিয়ে যেতে পারে।
- Chrome 154 (২২ সেপ্টেম্বর, ২০২৬): Webview Canary, Dev এবং Beta রিলিজ, আগাম সতর্কতা হিসেবে, ডিফল্ট হিসেবে XSLT বন্ধ করা শুরু করে।
- Chrome 158 (১৭ নভেম্বর, ২০২৬): অরিজিন ট্রায়াল এবং এন্টারপ্রাইজ নীতিতে অংশগ্রহণকারী ছাড়া অন্য সব ব্যবহারকারীর জন্য স্টেবল রিলিজে XSLT কাজ করা বন্ধ করে দেয়।
- Chrome 176 (১৭ আগস্ট, ২০২৭): অরিজিন ট্রায়াল ও এন্টারপ্রাইজ নীতি কাজ করা বন্ধ করে দেয়। সব ব্যবহারকারীর জন্য XSLT বন্ধ করা আছে।
XSLT কী?
XSLT বা এক্সটেনসিবল স্টাইলশিট ল্যাঙ্গুয়েজ ট্রান্সফর্মেশন হল এমন একটি ভাষা যা XML ডকুমেন্টকে অন্যান্য ফর্ম্যাটে (যেমন HTML) ট্রান্সফর্ম করতে ব্যবহার করা হয়। এটি এই কনভার্সনের নিয়মাবলী নির্ধারণ করতে XSLT স্টাইলশিট ফাইল এবং ইনপুট হিসেবে ব্যবহৃত ডেটা সহ XML ফাইল ব্যবহার করে।
ব্রাউজারে, যখন কোনও XML ফাইল পাওয়া যায় যা XSLT স্টাইলশিটের সাথে লিঙ্ক করা থাকে, তখন ব্রাউজার সেই স্টাইলশিটের নিয়ম ব্যবহার করে র-XML ডেটা সাজায়, ফর্ম্যাট করে এবং স্ট্রাকচার্ড পৃষ্ঠায় (প্রায়ই HTML) কনভার্ট করে যা ব্যবহারকারীর জন্য রেন্ডার করা যায়।
যেমন, XSLT স্টাইলশিট নিম্নলিখিত XML ইনপুট নিতে পারে:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
me>s<sage
> Hello World.
/message
/page
এবং এই XSL স্টাইলশিট:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
xsl:output meth>od=<"html"/
xsl:template m>atch=<&quo>t;/page</>message&q<uot;
body
pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//p
> /body
/xsl:template
/xsl:stylesheet
এবং ব্রাউজারে দেখানোর জন্য এই HTML-এ প্রসেস করুন: HTML
<body>
<p>Message: Hello World.</p>
</body>
আগের উদাহরণে দেখানো XSL প্রসেসিং নির্দেশাবলী ছাড়াও, XSLTProcessor JavaScript API-ও আছে যা লোকাল XSLT স্টাইলশিটের সাথে লোকাল XML ডকুমেন্ট প্রসেস করতে ব্যবহার করা যেতে পারে।
XSLT-এর ইতিহাস
XSLT-কে ওয়ার্ল্ড ওয়াইড ওয়েব কনসরশিয়াম (W3C) ১৬ নভেম্বর, ১৯৯৯-এ XML ডকুমেন্টকে অন্য ফর্ম্যাটে পরিবর্তন করার ভাষা হিসেবে রেকমেন্ড করে, সবচেয়ে সাধারণভাবে ওয়েব ব্রাউজারে দেখানোর জন্য HTML-এ পরিবর্তন করা হয়। অফিসিয়াল ১.০ সাজেশন আসার আগে, মাইক্রোসফ্ট মার্চ ১৯৯৯-এ রিলিজ হওয়া Internet Explorer 5.0-এ W3C ওয়ার্কিং ড্রাফ্টের উপর ভিত্তি করে একটি প্রোপ্রাইটারি ইমপ্লিমেন্টেশন শিপ করার মাধ্যমে একটি প্রাথমিক উদ্যোগ নিয়েছিল। অফিসিয়াল স্ট্যান্ডার্ড অনুসরণ করে, Mozilla ২০০০ সালের শেষের দিকে Netscape 6-এ নেটিভ XSLT 1.0 সাপোর্ট প্রয়োগ করেছে। Safari, Opera এবং Chrome-এর পরবর্তী ভার্সন সহ অন্যান্য প্রধান ব্রাউজারও নেটিভ XSLT 1.0 প্রসেসর অন্তর্ভুক্ত করেছে, যা ২০০০-এর দশকের শুরুতে ক্লায়েন্ট-সাইড XML-টু-HTML ট্রান্সফর্মেশনকে একটি কার্যকর ওয়েব প্রযুক্তি হিসেবে গড়ে তুলেছে।
XSLT ল্যাঙ্গুয়েজ নিজেই ক্রমাগত উন্নত হতে থাকে, ২০০৭ সালে XSLT 2.0 এবং ২০১৭ সালে XSLT 3.0 রিলিজ হয়, যা রেগুলার এক্সপ্রেশন, উন্নত ডেটার ধরন এবং JSON প্রসেস করার ক্ষমতার মতো শক্তিশালী ফিচার নিয়ে আসে। তবে, ব্রাউজার সাপোর্ট, থমকে গেছে। আজ, সমস্ত প্রধান ওয়েব ব্রাউজার ইঞ্জিন শুধুমাত্র ১৯৯৯ সালের আসল XSLT 1.0-এর জন্য নেটিভ সাপোর্ট প্রদান করে। এই অগ্রগতির অভাব, তার সাথে ওয়্যার ফর্ম্যাট হিসেবে JSON-এর ব্যবহার বৃদ্ধি এবং JavaScript লাইব্রেরি ও ফ্রেমওয়ার্ক (যেমন jQuery, React ও Vue.js) যা আরও নমনীয় ও শক্তিশালী DOM ম্যানিপুলেশন ও টেমপ্লেটিং অফার করে, তার ফলে ক্লায়েন্ট-সাইড XSLT-এর ব্যবহার উল্লেখযোগ্যভাবে হ্রাস পেয়েছে। ওয়েব ব্রাউজারে এর ভূমিকা জাভাস্ক্রিপ্ট-ভিত্তিক এই প্রযুক্তি দ্বারা অনেকাংশে স্থান অধিকার করা হয়েছে।
XSLT কেন সরাতে হবে?
ওয়েব ব্রাউজারে XSLT 1.0-এর ক্রমাগত অন্তর্ভুক্তি উল্লেখযোগ্য এবং অপ্রয়োজনীয় নিরাপত্তা ঝুঁকি তৈরি করে। এইসব ট্রান্সফর্মেশন প্রসেস করে এমন অন্তর্নিহিত লাইব্রেরি, যেমন libxslt (Chromium ব্রাউজার দ্বারা ব্যবহৃত), জটিল, পুরনো C/C++ কোডবেস। এই ধরনের কোড বাফার ওভারফ্লোর মতো মেমরি নিরাপত্তা সংক্রান্ত দুর্বলতার ক্ষেত্রে সহজেই প্রভাবিত হয়, যার ফলে ইচ্ছামতো কোড এক্সিকিউট হতে পারে। যেমন, নিরাপত্তা অডিট এবং বাগ ট্র্যাকার বারবার এই পার্সারগুলিতে (যেমন, CVE-2025-7425 এবং CVE-2022-22834, দুটিই libxslt-এ) উচ্চ-তীব্রতার দুর্বলতা শনাক্ত করেছে। যেহেতু ক্লায়েন্ট-সাইড XSLT এখন একটি বিশেষ, খুব কম ব্যবহৃত ফিচার, তাই এই লাইব্রেরিগুলি কোর জাভাস্ক্রিপ্ট ইঞ্জিনের তুলনায় অনেক কম রক্ষণাবেক্ষণ এবং নিরাপত্তা যাচাইকরণ পায়, তবুও তারা বিশ্বস্ত নয় এমন ওয়েব কন্টেন্ট প্রসেস করার জন্য একটি সরাসরি, শক্তিশালী অ্যাটাক সারফেস প্রতিনিধিত্ব করে। আসলে, XSLT হল সাম্প্রতিক বেশ কিছু হাই-প্রোফাইল নিরাপত্তা শোষণর উৎস যা ব্রাউজার ব্যবহারকারীদের ঝুঁকির মধ্যে ফেলে চলেছে। এই ভঙ্গুর, লিগ্যাসি কার্যকারিতা বজায় রাখার নিরাপত্তা সংক্রান্ত ঝুঁকি এর সীমিত আধুনিক উপযোগিতার চেয়ে অনেক বেশি।
এছাড়াও, ক্লায়েন্ট-সাইড XSLT-এর আসল উদ্দেশ্য—ডেটাকে রেন্ডার করা যায় এমন HTML-এ পরিবর্তন করা—নিরাপদ, আরও বেশি কর্মদক্ষতা সম্পন্ন এবং আরও ভালোভাবে রক্ষণাবেক্ষণ করা JavaScript API-এর মাধ্যমে প্রতিস্থাপিত হয়েছে। আধুনিক ওয়েব ডেভেলপমেন্ট ডেটা (সাধারণত JSON) ফিরিয়ে আনার জন্য Fetch API এবং ব্রাউজারের সুরক্ষিত জাভাস্ক্রিপ্ট স্যান্ডবক্সের মধ্যে DOM স্ট্রাকচারে XML বা HTML স্ট্রিং নিরাপদে পার্স করার জন্য DOMParser API-এর মতো বিষয়ের উপর নির্ভর করে। React, Vue এবং Svelte-এর মতো ফ্রেমওয়ার্ক তখন এই ডেটার রেন্ডারিং দক্ষতার সাথে এবং নিরাপদে ম্যানেজ করে। এই আধুনিক টুলচেন সক্রিয়ভাবে ডেভেলপ করা হয়, JavaScript ইঞ্জিনে বিপুল নিরাপত্তা সংক্রান্ত বিনিয়োগ থেকে সুবিধা পায় এবং বর্তমানে প্রায় সব ওয়েব ডেভেলপার এটি ব্যবহার করেন। আসলে, বর্তমানে ওয়েব পেজ লোড হওয়ার মাত্র ০.০২% ক্ষেত্রে XSLT ব্যবহার করা হয় এবং ০.০০১%-এরও কম ক্ষেত্রে XSLT প্রসেসিং নির্দেশাবলী ব্যবহার করা হয়।
এটি শুধু Chrome বা Chromium-এর অ্যাকশন নয়: অন্য দুটি প্রধান ব্রাউজার ইঞ্জিনও ওয়েব প্ল্যাটফর্ম থেকে XSLT সরিয়ে দেওয়ার ব্যাপারে সম্মতি জানিয়েছে: WebKit, Gecko.
এইসব কারণে, XSLT বাতিল ও সরিয়ে দিলে, সব ব্যবহারকারীর জন্য ব্রাউজারের অ্যাটাক সারফেস কমে যায়, ওয়েব প্ল্যাটফর্ম সহজ হয় এবং ইঞ্জিনিয়ারিং রিসোর্সকে সেইসব প্রযুক্তি সুরক্ষিত করার কাজে ব্যবহার করা যায় যেগুলি আসলে আধুনিক ওয়েবকে শক্তিশালী করে, এর ফলে ডেভেলপারদের ব্যবহারিক ক্ষমতার কোনও ক্ষতি হয় না।
XML পার্সিংয়ের নিরাপত্তা উন্নত করা হচ্ছে
libxslt-এ গুরুতর নিরাপত্তা সংক্রান্ত সমস্যার মতো, libxml2-এর বিরুদ্ধে সম্প্রতি গুরুতর নিরাপত্তা সংক্রান্ত সমস্যা রিপোর্ট করা হয়েছে, যা Chromium-এ পার্সিং, সিরিয়ালাইজেশন এবং XML-এর সুগঠিততা পরীক্ষা করার জন্য ব্যবহৃত হয়। Chromium-এ XML পার্সিংয়ের ক্ষেত্রে ভবিষ্যতে নিরাপত্তা সংক্রান্ত সমস্যা সমাধান করতে, আমরা libxml2-এর ব্যবহার ধীরে ধীরে বন্ধ করার পরিকল্পনা করেছি এবং XML পার্সিংয়ের পরিবর্তে Rust-এ লেখা মেমরি-সেফ XML পার্সিং লাইব্রেরি ব্যবহার করব। গুরুত্বপূর্ণ বিষয় হল, আমরা ব্রাউজার থেকে XML সরাব না; এখানে শুধু XSLT সরানোর কথা বিবেচনা করা হচ্ছে। আমরা নিশ্চিত করতে চাই যে libxml2-এর পরিবর্তন ওয়েব ডেভেলপারদের কাছে সম্পূর্ণ স্বচ্ছ।
XML + CSS সরানো হচ্ছে না
XSLT (<?xml-stylesheet type="text/xsl" ... ?>) বন্ধ হয়ে যাওয়া এবং <?xml-stylesheet ... ?> প্রসেসিং নির্দেশাবলীর মধ্যে পার্থক্য করা গুরুত্বপূর্ণ, যা CSS-এর সাথে ব্যবহার করার সময় কাজ করে। আপনি এখনও HTML-এর মতোই
type="text/css"-এর সাথে প্রসেসিং নির্দেশাবলী ব্যবহার করে আপনার র ডেটাতে স্ট্যান্ডার্ড লেআউট এবং ডিজাইন নিয়ম প্রয়োগ করতে পারেন। যেমন:
<?xml version="1.0" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
itemContent here/item
/root
কীভাবে মাইগ্রেট করবেন
মাইগ্রেশনের জন্য কিছু বিকল্প পথ আছে।
JSON
XML ও XSL-এর উপর সম্পূর্ণভাবে তৈরি সাইটের ক্ষেত্রে, ট্রানজিশন করার জন্য কোনও নির্দিষ্ট উপায় নেই। মাইগ্রেশন বিকল্পের মধ্যে রয়েছে, XSLT প্রসেসিং পাইপলাইনকে সার্ভার সাইডে সরানো এবং রেন্ডার করা HTML ক্লায়েন্টের কাছে পাঠানো অথবা সার্ভার-সাইড XML API এন্ডপয়েন্টকে JSON-এ মাইগ্রেট করা এবং JavaScript ব্যবহার করে ক্লায়েন্ট-সাইড রেন্ডারিং করা যাতে JSON-কে HTML DOM ও CSS-এ পরিবর্তন করা যায়।
জাভাস্ক্রিপ্টে ক্লায়েন্ট-সাইড XSLT
কয়েকটি ক্লায়েন্ট-সাইড (JavaScript-ভিত্তিক) XSLT লাইব্রেরি উপলভ্য আছে, তবে সবচেয়ে বড়টি তৈরি করেছে Saxonica ( Saxonica-র জন্য বিস্তারিত ডকুমেন্টেশন দেখুন)। এই ইমপ্লিমেন্টেশন ওয়েব ব্রাউজারে XSLT 1.0 ইমপ্লিমেন্টেশনের থেকে অনেক বেশি কার্যকর, লেটেস্ট v3.0 স্ট্যান্ডার্ড এবং অবশেষে প্রোগ্রেসে থাকা v4.0 স্ট্যান্ডার্ড-এর জন্য সম্পূর্ণ সহায়তা ইমপ্লিমেন্ট করা।
পলিফিল
একটি পলিফিল আছে যা বিদ্যমান কোডকে অনুমতি দেওয়ার চেষ্টা করে, যা ওয়েবের উপর নির্ভর করে XSLT 1.0-এর ব্রাউজার বাস্তবায়ন, কাজ চালিয়ে যেতে, ব্যবহার না করার সময় ব্রাউজার থেকে নেটিভ XSLT ফিচার। পলিফিল GitHub-এ রয়েছে।
পলিফিলে XSLTProcessor ক্লাসের জন্য একটি ফাংশনাল WASM-ভিত্তিক পলিফিল্ড রিপ্লেসমেন্ট রয়েছে, তাই বিদ্যমান জাভাস্ক্রিপ্ট কোড আগের মতোই কাজ চালিয়ে যেতে পারে:
<script src="xslt-polyfill.mi><n.js&qu>ot<;/scri>pt
script
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, d<ocument>);
/script
এছাড়াও, পলিফিল, XSLT প্রসেসিং নির্দেশাবলী ব্যবহার করে এমন XML ডকুমেন্ট সহজে পরিবর্তন করার জন্য একটি অটোমেটিক ইউটিলিটি ফাংশন প্রদান করে:
এই ধরনের আসল demo.xml ফাইলের জন্য:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...
পলিফিল ইনভোক করতে এবং রেফারেন্স করা XSLT স্টাইলশিটের সাথে ডকুমেন্ট ট্রান্সফর্ম করতে একটি লাইন যোগ করা যেতে পারে:
<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
xml>ns="http://www.w3.org/1999/xhtml"/script
...content...
এই ক্ষেত্রে, নতুন <script> এলিমেন্ট পলিফিল লোড করে, যা XML ডকুমেন্টের ধরন এবং XSLT প্রসেসিং নির্দেশ শনাক্ত করে এবং ডকুমেন্টটি প্রতিস্থাপন করে স্বচ্ছভাবে লোড করে।
এক্সটেনশন
এছাড়াও, একটি Chrome এক্সটেনশন আছে যা কাজ করে এমন ব্রাউজারে যোগ করা যেতে পারে, যা XSLT প্রসেসিং নির্দেশাবলী বা XSLTProcessor-এ কল সহ সমস্ত কাঁচা XML পৃষ্ঠায় একই XSLT পলিফিল প্রয়োগ করবে। কার্যকারিতা বজায় রাখার জন্য, সোর্স XML বা XSLT পরিবর্তন করা যায় না এমন অ্যাপ্লিকেশনের ক্ষেত্রে এটি ব্যবহার করা যেতে পারে।
বিশেষ করে, XSLT বন্ধ করা থাকলে, Chrome এখন একটি সতর্কতামূলক ব্যানার দেখায় যা সরাসরি এক্সটেনশন সার্চ পৃষ্ঠার সাথে লিঙ্ক করে, যাতে ব্যবহারকারীরা এক্সটেনশন খুঁজে পেতে পারেন:
নির্দিষ্ট ব্যবহারের উদাহরণ
HTML স্ট্যান্ডার্ডে আলোচনা করার সময়, বেশ কিছু নির্দিষ্ট ব্যবহারের ঘটনা শনাক্ত করা হয়েছে। এই বিভাগে এগুলির প্রত্যেকটি সম্পর্কে নির্দিষ্টভাবে আলোচনা করা হয়েছে, যাতে বর্তমানে XSLT ব্যবহার করে XML রিসোর্স প্রকাশ করা ডেভেলপারদের জন্য উপযুক্ত পথ সাজেস্ট করা যায়।
RSS এবং অ্যাটম ফীডস
আগে থেকে থাকা অনেক RSS বা Atom ফিডে, ব্রাউজারে সরাসরি দেখার সময় র-XML ফিডকে মানুষের-পঠনযোগ্য করে তুলতে XSLT ব্যবহার করা হয়। প্রাথমিক ব্যবহারের ক্ষেত্রে, কোনও ব্যবহারকারী কোনও সাইটের RSS ফিড লিঙ্কে ভুলবশত ক্লিক করলে, সেই লিঙ্কটি তার RSS রিডারে পেস্ট করার পরিবর্তে, তিনি একটি ফর্ম্যাট করা HTML উত্তর পান যা তিনি পড়তে পারেন, র-XML-এর পরিবর্তে।
এই ব্যবহারের ক্ষেত্রে দুটি পথ আছে। এটি করার "স্ট্যান্ডার্ড" 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> হল রুট এলিমেন্টের সরাসরি চাইল্ড।
এম্বেড করা ডিভাইসের জন্য API আউটপুট
কিছু বাণিজ্যিক এম্বেড করা ডিভাইস স্থানীয় নেটওয়ার্কে ব্যবহারকারীদের ব্যবহারের জন্য XML ডেটা পরিমাপ করে বা অন্যথায় তৈরি করে। এইসব ডিভাইসের মধ্যে কিছু ডিভাইস একটি XML ডেটা ফিড তৈরি করে এটি করে যা XSLT ব্যবহার করে এটিকে মানুষের-পঠনযোগ্য HTML ফর্ম্যাটে রূপান্তরিত করে। এর ফলে, ডিভাইস বা ব্রাউজারে অতিরিক্ত কোড ছাড়াই সরাসরি ব্রাউজারে API দেখা যায়।
যেহেতু এটি একটি খুব অ্যাপ্লিকেশন নির্দিষ্ট ব্যবহারের কেস, তাই সমাধানের আকার
পরিবর্তিত হতে পারে। যেসব অ্যাপ্লিকেশনে এম্বেড করা ডিভাইসের সোর্স কোড আপডেট করা যায়, সেগুলির ক্ষেত্রে আগে উল্লেখ করা যেকোনও বিকল্প (JSON, Polyfill) কাজ করতে পারে। তবে,
বিশেষ করে, বিভিন্ন কারণে এই ধরনের অনেক ডিভাইস আপডেট করা কঠিন বা অসম্ভব। সেই ক্ষেত্রে,
এক্সটেনশন
সম্ভবত সেরা বিকল্প, কারণ এটি ক্লায়েন্ট ব্রাউজারকে ডিভাইস পরিবর্তন না করেই ঠিক একইভাবে ডেটা পড়া চালিয়ে যেতে দেয়।
ওয়েবসাইটের জন্য লেজি টেমপ্লেটিং
ওয়েব ডেভেলপাররা কখনও কখনও ক্লায়েন্ট সাইডে XSLT ব্যবহার করে প্রেজেন্টেশন মার্কআপকে সিম্যান্টিক মার্কআপে প্রয়োগ করেন, যা জাভাস্ক্রিপ্ট ইকোসিস্টেম থেকে আলাদা লেজি টেমপ্লেটিং ল্যাঙ্গুয়েজ হিসেবে কাজ করে।
এই সাধারণ সমস্যার দুটি সমাধান আছে। এইভাবে তৈরি করা কোনও সাইটের ক্ষেত্রে, সবচেয়ে সহজ সমাধান হল, আগে থেকে থাকা কার্যকারিতা বজায় রাখার জন্য পলিফিল যোগ করা। অথবা, সার্ভার সাইডে XSLT ট্রান্সফর্মেশন করে, র-XML-এর পরিবর্তে, ফলাফল হিসেবে পাওয়া HTML ক্লায়েন্টকে পরিবেশন করুন। এই ধরনের প্রপার্টির জন্য আরও দীর্ঘমেয়াদী সমাধান হল আরও আধুনিক JavaScript বা JSON-ভিত্তিক ফ্রেমওয়ার্কে মাইগ্রেট করা।
এই XSLT বন্ধ হয়ে যাওয়া সম্পর্কিত কোনও নির্দিষ্ট সমস্যার সম্মুখীন হলে, এখানে সমস্যার বিষয়ে অভিযোগ জানান।
XSLT-এর ব্যবহার কীভাবে শনাক্ত করবেন
সাধারণত, XSLT-এর মতো বন্ধ হয়ে যাওয়া ফিচার আপনার কোডবেসে কয়েকটি উপায়ে শনাক্ত করা যেতে পারে। এই বিভাগে তার মধ্যে দুটি উল্লেখ করা হয়েছে।
Reporting API
Reporting API হল ওয়েব অ্যাপ্লিকেশনের জন্য একটি সাধারণ রিপোর্টিং মেকানিজম যা বিভিন্ন প্ল্যাটফর্ম ফিচার ও শর্তের রিপোর্ট ব্যবহার করে, যার মধ্যে ফিচার বন্ধ হয়ে যাওয়ার মতো বিষয়ও অন্তর্ভুক্ত। 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-এ এই কোড কীভাবে কাজ করে তা দেখুন।
এন্টারপ্রাইজ লিগ্যাসি টেকনোলজি রিপোর্ট
কোনও এন্টারপ্রাইজের অ্যাডমিনদের জন্য, লিগ্যাসি প্রযুক্তি রিপোর্ট ব্যবহার করে অপ্রচলিত ফিচারের ব্যবহার অটোমেটিক সংগ্রহ করা এবং ব্যবহারকারীর জন্য সুবিধাজনক উপায়ে রিপোর্ট করা যেতে পারে। এই ফিচার কীভাবে চালু করবেন সেই সম্পর্কে আরও তথ্য পেতে, এই Google সহায়তা নিবন্ধ দেখুন।