প্রকাশিত: ২৯ অক্টোবর, ২০২৫
Chrome ব্রাউজার থেকে XSLT কে অবচয় এবং অপসারণ করতে চায়। এই নথিতে ২০২৬ সালের শেষের দিকে অপসারণের আগে আপনি কীভাবে আপনার কোডটি স্থানান্তর করতে পারবেন তার বিশদ বিবরণ দেওয়া হয়েছে।
Chromium আনুষ্ঠানিকভাবে XSLT কে বাতিল করেছে, যার মধ্যে XSLTProcessor JavaScript API এবং XML স্টাইলশিট প্রক্রিয়াকরণ নির্দেশিকাও রয়েছে। আমরা 155 সংস্করণ (17 নভেম্বর, 2026) থেকে সমর্থন অপসারণের পরিকল্পনা করছি। Firefox এবং WebKit প্রকল্পগুলি তাদের ব্রাউজার ইঞ্জিন থেকে XSLT অপসারণের পরিকল্পনার ইঙ্গিতও দিয়েছে। এই নথিতে কিছু ইতিহাস এবং প্রেক্ষাপট প্রদান করা হয়েছে, Chrome কে নিরাপদ করার জন্য আমরা কীভাবে XSLT অপসারণ করছি তা ব্যাখ্যা করা হয়েছে এবং ব্রাউজার থেকে এই বৈশিষ্ট্যগুলি সরানোর আগে স্থানান্তরের জন্য একটি পথ প্রদান করা হয়েছে।
কী সরানো হচ্ছে?
ব্রাউজারে দুটি API আছে যা XSLT বাস্তবায়ন করে, এবং উভয়ই সরানো হচ্ছে:
- XSLTProcessor ক্লাস (উদাহরণস্বরূপ,
new XSLTProcessor())। - XSLT প্রক্রিয়াকরণ নির্দেশিকা (উদাহরণস্বরূপ,
<?xml-stylesheet … ?>)।
Chrome এর জন্য টাইমলাইন
Chrome এর নিম্নলিখিত পরিকল্পনা রয়েছে:
- Chrome 142 (২৮ অক্টোবর, ২০২৫): Chrome-এ পূর্ব সতর্কতা কনসোল বার্তা যোগ করা হয়েছে।
- Chrome 143 (২ ডিসেম্বর, ২০২৫): API-এর আনুষ্ঠানিক অবচয় - অবচয় সতর্কতা বার্তা কনসোল এবং লাইটহাউসে প্রদর্শিত হতে শুরু করে।
- Chrome 148 (মার্চ ১০, ২০২৬ ক্যানারি): ক্যানারি, ডেভ এবং বিটা রিলিজগুলি পূর্ব-সতর্কতা হিসাবে ডিফল্টরূপে XSLT নিষ্ক্রিয় করা শুরু করে।
- Chrome 152 (২৫ আগস্ট, ২০২৬): অরিজিন ট্রায়াল (OT) এবং এন্টারপ্রাইজ পলিসি (EP) পরীক্ষার জন্য লাইভ হয়। এর ফলে সাইট এবং এন্টারপ্রাইজগুলি অপসারণের তারিখের পরেও বৈশিষ্ট্যগুলি ব্যবহার চালিয়ে যেতে পারে।
- Chrome 155 (১৭ নভেম্বর, ২০২৬): XSLT স্টেবল রিলিজে কাজ করা বন্ধ করে দেয়, অরিজিন ট্রায়াল এবং এন্টারপ্রাইজ পলিসি অংশগ্রহণকারী ছাড়া অন্য সকল ব্যবহারকারীর জন্য।**
- Chrome 164 (আগস্ট ১৭, ২০২৭): অরিজিন ট্রায়াল এবং এন্টারপ্রাইজ পলিসি কাজ করা বন্ধ করে দিয়েছে। 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 JavaScript APIও রয়েছে যা স্থানীয় XSLT স্টাইলশিট দিয়ে স্থানীয় XML ডকুমেন্ট প্রক্রিয়া করতে ব্যবহার করা যেতে পারে।
XSLT এর ইতিহাস
১৯৯৯ সালের ১৬ নভেম্বর ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম (W3C) XSLT-কে XML ডকুমেন্টগুলিকে অন্যান্য ফর্ম্যাটে রূপান্তর করার জন্য একটি ভাষা হিসেবে সুপারিশ করেছিল, যা সাধারণত ওয়েব ব্রাউজারে প্রদর্শনের জন্য HTML। অফিসিয়াল ১.০ সুপারিশের আগে, মাইক্রোসফ্ট ১৯৯৯ সালের মার্চ মাসে প্রকাশিত ইন্টারনেট এক্সপ্লোরার ৫.০- তে W3C ওয়ার্কিং ড্রাফ্টের উপর ভিত্তি করে একটি মালিকানাধীন বাস্তবায়ন প্রেরণ করে প্রাথমিক উদ্যোগ নিয়েছিল। অফিসিয়াল স্ট্যান্ডার্ড অনুসরণ করে, মোজিলা ২০০০ সালের শেষের দিকে নেটস্কেপ ৬- এ নেটিভ XSLT ১.০ সমর্থন বাস্তবায়ন করে। সাফারি, অপেরা এবং পরবর্তীতে ক্রোম সহ অন্যান্য প্রধান ব্রাউজারগুলিও নেটিভ XSLT ১.০ প্রসেসর অন্তর্ভুক্ত করে, যা ২০০০-এর দশকের গোড়ার দিকে ক্লায়েন্ট-সাইড XML-থেকে-HTML রূপান্তরকে একটি কার্যকর ওয়েব প্রযুক্তিতে পরিণত করে।
২০০৭ সালে XSLT 2.0 এবং ২০১৭ সালে XSLT 3.0 প্রকাশের সাথে সাথে XSLT ভাষা নিজেই বিকশিত হতে থাকে, যা নিয়মিত এক্সপ্রেশন, উন্নত ডেটা টাইপ এবং JSON প্রক্রিয়াকরণের ক্ষমতার মতো শক্তিশালী বৈশিষ্ট্যগুলি চালু করে। তবে, ব্রাউজার সমর্থন স্থবির হয়ে পড়ে। আজ, সমস্ত প্রধান ওয়েব ব্রাউজার ইঞ্জিনগুলি ১৯৯৯ সালের মূল XSLT 1.0 এর জন্য কেবল নেটিভ সমর্থন প্রদান করে। এই অগ্রগতির অভাব, ওয়্যার ফর্ম্যাট হিসাবে JSON এর ব্যবহারের উত্থানের সাথে মিলিত হয় এবং জাভাস্ক্রিপ্ট লাইব্রেরি এবং ফ্রেমওয়ার্ক (যেমন 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-এ রূপান্তর—এর পরিবর্তে নিরাপদ, আরও এর্গোনমিক এবং উন্নত রক্ষণাবেক্ষণযোগ্য জাভাস্ক্রিপ্ট API ব্যবহার করা হয়েছে। আধুনিক ওয়েব ডেভেলপমেন্ট ডেটা পুনরুদ্ধারের জন্য Fetch API (সাধারণত JSON) এবং ব্রাউজারের নিরাপদ জাভাস্ক্রিপ্ট স্যান্ডবক্সের মধ্যে XML বা HTML স্ট্রিংগুলিকে নিরাপদে একটি DOM কাঠামোতে পার্স করার জন্য DOMParser API-এর মতো জিনিসের উপর নির্ভর করে। React, Vue এবং Svelte-এর মতো ফ্রেমওয়ার্কগুলি তখন এই ডেটার রেন্ডারিং দক্ষতার সাথে এবং নিরাপদে পরিচালনা করে। এই আধুনিক টুলচেইনটি সক্রিয়ভাবে তৈরি করা হয়েছে, জাভাস্ক্রিপ্ট ইঞ্জিনে বিশাল নিরাপত্তা বিনিয়োগ থেকে উপকৃত হয় এবং আজকাল কার্যত সমস্ত ওয়েব ডেভেলপার এটিই ব্যবহার করে। প্রকৃতপক্ষে, আজকাল ওয়েব পৃষ্ঠা লোডের মাত্র 0.02% আসলে XSLT ব্যবহার করে, যেখানে 0.001% -এরও কম XSLT প্রক্রিয়াকরণ নির্দেশাবলী ব্যবহার করে।
এটি কেবল ক্রোম বা ক্রোমিয়াম-ভিত্তিক কোনও পদক্ষেপ নয়: অন্য দুটি প্রধান ব্রাউজার ইঞ্জিনও ওয়েব প্ল্যাটফর্ম থেকে XSLT অপসারণকে সমর্থন করে: WebKit , Gecko ।
এই কারণে, XSLT কে অবহেলা এবং অপসারণ করলে সকল ব্যবহারকারীর জন্য ব্রাউজারের আক্রমণের পৃষ্ঠ হ্রাস পায়, ওয়েব প্ল্যাটফর্মকে সরল করা যায় এবং প্রকৌশল সংস্থানগুলিকে আধুনিক ওয়েবকে প্রকৃতপক্ষে শক্তিশালী করে এমন প্রযুক্তিগুলি সুরক্ষিত করার উপর দৃষ্টি নিবদ্ধ করার সুযোগ দেওয়া হয়, যার ফলে ডেভেলপারদের কার্যত ক্ষমতার কোনও ক্ষতি হয় না।
XML পার্সিং নিরাপত্তা উন্নত করা হচ্ছে
libxslt-এর গুরুতর নিরাপত্তা সমস্যার মতো, সম্প্রতি libxml2-এর বিরুদ্ধেও গুরুতর নিরাপত্তা সমস্যা রিপোর্ট করা হয়েছে, যা Chromium-এ XML-এর পার্সিং, সিরিয়ালাইজেশন এবং সুগঠন পরীক্ষা করার জন্য ব্যবহৃত হয়। XML পার্সিংয়ের সাথে ভবিষ্যতের নিরাপত্তা সমস্যাগুলি সমাধান করার জন্য Chromium-এ আমরা libxml2-এর ব্যবহার পর্যায়ক্রমে বন্ধ করার এবং Rust-এ লেখা একটি মেমরি-নিরাপদ XML পার্সিং লাইব্রেরি দিয়ে XML পার্সিং প্রতিস্থাপন করার পরিকল্পনা করছি। গুরুত্বপূর্ণ বিষয় হল, আমরা ব্রাউজার থেকে XML অপসারণ করব না; এখানে শুধুমাত্র XSLT অপসারণের জন্য বিবেচনা করা হচ্ছে। আমরা নিশ্চিত করতে চাই যে libxml2 প্রতিস্থাপন ওয়েব ডেভেলপারদের কাছে সম্পূর্ণ স্বচ্ছ।
কিভাবে মাইগ্রেট করবেন
অভিবাসনের জন্য কয়েকটি বিকল্প পথ রয়েছে।
JSON সম্পর্কে
সম্পূর্ণরূপে XML এবং XSL-এর উপর ভিত্তি করে তৈরি সাইটগুলির জন্য, রূপান্তরটি করার জন্য কোনও এক-আকার-ফিট পদ্ধতি নেই। মাইগ্রেশন বিকল্পগুলির মধ্যে রয়েছে XSLT প্রসেসিং পাইপলাইনকে সার্ভার সাইডে স্থানান্তর করা এবং রেন্ডার করা HTML ক্লায়েন্টে পাঠানো, অথবা সার্ভার-সাইড XML API এন্ডপয়েন্টগুলিকে JSON- এ স্থানান্তর করা, এবং JSON-কে HTML DOM এবং CSS-এ রূপান্তর করার জন্য JavaScript ব্যবহার করে ক্লায়েন্ট-সাইড রেন্ডারিং করা।
জাভাস্ক্রিপ্টে ক্লায়েন্ট-সাইড XSLT
কয়েকটি ক্লায়েন্ট-সাইড (জাভাস্ক্রিপ্ট-ভিত্তিক) XSLT লাইব্রেরি উপলব্ধ, তবে এখন পর্যন্ত সবচেয়ে বড়টি Saxonica দ্বারা তৈরি করা হয়েছে ( Saxonica এর জন্য বিস্তৃত ডকুমেন্টেশন দেখুন)। বাস্তবায়নটি ওয়েব ব্রাউজারগুলিতে XSLT 1.0 বাস্তবায়নের চেয়ে অনেক বেশি, সর্বশেষ v3.0 স্ট্যান্ডার্ডের জন্য সম্পূর্ণ সমর্থন বাস্তবায়ন করে এবং অবশেষে অগ্রগতিশীল v4.0 স্ট্যান্ডার্ড ।
পলিফিল
একটি পলিফিল আছে যা বিদ্যমান কোডকে, যা ওয়েব ব্রাউজারগুলির XSLT 1.0 বাস্তবায়নের উপর নির্ভর করে, কাজ চালিয়ে যাওয়ার অনুমতি দেওয়ার চেষ্টা করে, ব্রাউজার থেকে নেটিভ XSLT বৈশিষ্ট্য ব্যবহার না করে। পলিফিলটি GitHub-এ অবস্থিত ।
পলিফিলটিতে 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 প্রক্রিয়াকরণ নির্দেশ সনাক্ত করে এবং স্বচ্ছভাবে এটি লোড করে, ডকুমেন্টটি প্রতিস্থাপন করে।
এক্সটেনশন
সমর্থিত ব্রাউজারগুলিতে যোগ করা যেতে পারে এমন একটি Chrome এক্সটেনশনও রয়েছে, যা XSLT প্রক্রিয়াকরণ নির্দেশাবলী বা XSLTProcessor-এ কল ধারণকারী সমস্ত raw XML পৃষ্ঠাগুলিতে একই XSLT পলিফিল প্রয়োগ করবে। কার্যকারিতা বজায় রাখার জন্য এটি এমন অ্যাপ্লিকেশনগুলির জন্য ব্যবহার করা যেতে পারে যেখানে উৎস XML বা XSLT পরিবর্তন করা যায় না।
বিশেষ করে, যখন XSLT নিষ্ক্রিয় করা হয়, তখন Chrome এখন একটি সতর্কতামূলক ব্যানার দেখায় যা সরাসরি একটি এক্সটেনশন অনুসন্ধান পৃষ্ঠার সাথে লিঙ্ক করে, যাতে ব্যবহারকারীরা একটি এক্সটেনশন খুঁজে পেতে পারেন:
নির্দিষ্ট ব্যবহারের ক্ষেত্রে
HTML স্ট্যান্ডার্ডের আলোচনায় , বেশ কিছু নির্দিষ্ট ব্যবহারের ঘটনা চিহ্নিত করা হয়েছে। এই বিভাগটি বিশেষভাবে তাদের প্রতিটি সম্পর্কে আলোচনা করে, যা বর্তমানে XSLT ব্যবহার করে XML রিসোর্স প্রকাশকারী ডেভেলপারদের জন্য ভবিষ্যতের পথগুলি সুপারিশ করে।
আরএসএস এবং অ্যাটম ফিডস
অনেক বিদ্যমান RSS বা Atom ফিডে, XSLT ব্যবহার করা হয় raw XML ফিডগুলিকে সরাসরি ব্রাউজারে দেখা গেলে মানুষের পঠনযোগ্য করে তুলতে। প্রাথমিক ব্যবহারের ক্ষেত্রে হল যখন কোনও ব্যবহারকারী ভুলবশত কোনও সাইটের RSS ফিড লিঙ্কে ক্লিক করে, সেই লিঙ্কটি তাদের RSS রিডারে পেস্ট করার পরিবর্তে, তারা একটি ফর্ম্যাট করা HTML প্রতিক্রিয়া পায় যা তারা raw 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](http://www.w3.org/1999/xhtml)"></script> , যা XSLT-ভিত্তিক HTML রূপান্তরের বিদ্যমান আচরণ বজায় রাখবে। এটি RSS পাঠকের XML পার্সিং চালিয়ে যাওয়ার ক্ষমতাকে প্রভাবিত করবে না, কারণ <script> হল মূল উপাদানের একটি সরাসরি সন্তান।
এমবেডেড ডিভাইসের জন্য API আউটপুট
কিছু বাণিজ্যিক এমবেডেড ডিভাইস স্থানীয় নেটওয়ার্কে ব্যবহারকারীদের ব্যবহারের জন্য XML ডেটা পরিমাপ করে বা অন্যথায় তৈরি করে। এই ডিভাইসগুলির মধ্যে কিছু একটি একক XML ডেটা ফিড তৈরি করে এটি করে যা XSLT ব্যবহার করে এটিকে মানব-পঠনযোগ্য HTML ফর্ম্যাটে রূপান্তরিত করে। এটি ডিভাইসে বা ব্রাউজারে অতিরিক্ত কোডের প্রয়োজন ছাড়াই API সরাসরি ব্রাউজারে দেখার অনুমতি দেয়।
যেহেতু এটি একটি অত্যন্ত অ্যাপ্লিকেশন-নির্দিষ্ট ব্যবহারের ক্ষেত্রে, সমাধানের আকার ভিন্ন হতে পারে। যেসব অ্যাপ্লিকেশনে এমবেডেড ডিভাইসের সোর্স কোড আপডেট করা যেতে পারে, সেখানে পূর্বে বর্ণিত যেকোনো বিকল্প (JSON, Polyfill) কাজ করতে পারে। বিশেষ করে, তবে, বিভিন্ন কারণে এই ধরনের অনেক ডিভাইস আপডেট করা কঠিন বা অসম্ভব। সেক্ষেত্রে, এক্সটেনশনটি সম্ভবত সেরা বিকল্প, কারণ এটি ক্লায়েন্ট ব্রাউজারগুলিকে ডিভাইসটি পরিবর্তন না করেই ঠিক একইভাবে ডেটা পড়া চালিয়ে যেতে দেয়।
ওয়েবসাইটের জন্য অলস টেমপ্লেটিং
ওয়েব ডেভেলপাররা কখনও কখনও ক্লায়েন্ট সাইডে XSLT ব্যবহার করে সিমেন্টিক মার্কআপে প্রেজেন্টেশন মার্কআপ প্রয়োগ করে, যা জাভাস্ক্রিপ্ট ইকোসিস্টেম থেকে আলাদা একটি অলস টেমপ্লেটিং ভাষা হিসেবে কাজ করে।
এই সাধারণ সমস্যার দুটি সমাধান আছে। এইভাবে তৈরি একটি বিদ্যমান সাইটের জন্য, সবচেয়ে সহজ সমাধান হল বিদ্যমান কার্যকারিতা বজায় রাখার জন্য পলিফিল যোগ করা। অথবা সার্ভার সাইডে XSLT রূপান্তর সম্পাদন করা এবং কাঁচা XML-এর পরিবর্তে ক্লায়েন্টকে ফলাফল HTML পরিবেশন করা। এই ধরনের বৈশিষ্ট্যের জন্য দীর্ঘমেয়াদী সমাধান হবে আরও আধুনিক জাভাস্ক্রিপ্ট বা JSON-ভিত্তিক ফ্রেমওয়ার্কে স্থানান্তর করা।