पब्लिश होने की तारीख: 29 अक्टूबर, 2025
Chrome, ब्राउज़र से XSLT को बंद करने और हटाने का इरादा रखता है. इस दस्तावेज़ में, कोड को हटाने से पहले माइग्रेट करने का तरीका बताया गया है. कोड को 2026 के आखिर में हटा दिया जाएगा.
Chromium ने आधिकारिक तौर पर XSLT को बंद कर दिया है. इसमें XSLTProcessor JavaScript API और XML स्टाइलशीट प्रोसेसिंग के निर्देश शामिल हैं. हम 17 नवंबर, 2026 से वर्शन 155 के लिए सहायता देना बंद कर देंगे. Firefox और WebKit प्रोजेक्ट ने भी, अपनी ब्राउज़र इंजन से XSLT को हटाने के प्लान के बारे में बताया है. इस दस्तावेज़ में, XSLT के बारे में कुछ जानकारी और कॉन्टेक्स्ट दिया गया है. इसमें बताया गया है कि Chrome को ज़्यादा सुरक्षित बनाने के लिए, हम XSLT को कैसे हटा रहे हैं. साथ ही, इन सुविधाओं को ब्राउज़र से हटाने से पहले माइग्रेट करने का तरीका बताया गया है.
क्या हटाया जा रहा है?
ब्राउज़र में दो ऐसे एपीआई हैं जो XSLT लागू करते हैं. इन दोनों को हटाया जा रहा है:
- XSLTProcessor क्लास (उदाहरण के लिए,
new XSLTProcessor()). - XSLT प्रोसेसिंग
निर्देश
(उदाहरण के लिए,
<?xml-stylesheet … ?>).
Chrome के लिए टाइमलाइन
Chrome का यह प्लान है:
- Chrome 142 (28 अक्टूबर, 2025): Chrome में अर्ली वार्निंग कंसोल मैसेज जोड़े गए.
- Chrome 143 (2 दिसंबर, 2025): एपीआई को आधिकारिक तौर पर बंद कर दिया जाएगा - बंद होने की चेतावनी वाले मैसेज, कंसोल और Lighthouse में दिखने लगेंगे.
- Chrome 148 (10 मार्च, 2026 कैनरी): कैनरी, डेव, और बीटा वर्शन में, XSLT को डिफ़ॉल्ट रूप से बंद करने की सुविधा शुरू की जाएगी. यह सुविधा, पहले से दी जाने वाली चेतावनी के तौर पर उपलब्ध होगी.
- Chrome 152 (25 अगस्त, 2026): टेस्टिंग के लिए, ऑरिजिन ट्रायल (ओटी) और एंटरप्राइज़ नीति (ईपी) उपलब्ध होगी. इन कुकी की मदद से, साइटें और कंपनियां सुविधा के बंद होने की तारीख के बाद भी उसका इस्तेमाल जारी रख सकती हैं.
- Chrome 155 (17 नवंबर, 2026): XSLT, स्टेबल रिलीज़ पर काम नहीं करेगा. यह सुविधा, Origin Trial और Enterprise Policy में हिस्सा लेने वाले लोगों के अलावा, सभी उपयोगकर्ताओं के लिए बंद कर दी जाएगी.**
- Chrome 164 (17 अगस्त, 2027): ऑरिजिन ट्रायल और Enterprise की नीति काम करना बंद कर देगी. सभी उपयोगकर्ताओं के लिए XSLT बंद है.**
XSLT क्या है?
एक्सएसएलटी या एक्सटेंसिबल स्टाइलशीट लैंग्वेज ट्रांसफ़ॉर्मेशन, एक ऐसी भाषा है जिसका इस्तेमाल एक्सएमएल दस्तावेज़ों को बदलने के लिए किया जाता है. आम तौर पर, इन्हें एचटीएमएल जैसे अन्य फ़ॉर्मैट में बदला जाता है. यह कन्वर्ज़न के नियमों को तय करने के लिए, XSLT स्टाइलशीट फ़ाइल का इस्तेमाल करता है. साथ ही, इनपुट के तौर पर इस्तेमाल किए गए डेटा वाली एक्सएमएल फ़ाइल का इस्तेमाल करता है.
ब्राउज़र में, जब कोई ऐसी एक्सएमएल फ़ाइल मिलती है जो किसी XSLT स्टाइलशीट से लिंक होती है, तो ब्राउज़र उस स्टाइलशीट में दिए गए नियमों का इस्तेमाल करता है. इससे वह रॉ एक्सएमएल डेटा को व्यवस्थित करता है, उसे फ़ॉर्मैट करता है, और उसे स्ट्रक्चर्ड पेज (अक्सर एचटीएमएल) में बदलता है. इस पेज को उपयोगकर्ता के लिए रेंडर किया जा सकता है.
उदाहरण के लिए, कोई XSLT स्टाइलशीट, इस तरह का एक्सएमएल इनपुट ले सकती है:
<?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>
और ब्राउज़र में दिखाने के लिए, उन्हें इस एचटीएमएल में प्रोसेस करता है: एचटीएमएल
<body>
<p>Message: Hello World.</p>
</body>
पिछले उदाहरण में दिखाए गए XSL प्रोसेसिंग इंस्ट्रक्शन के अलावा, XSLTProcessor JavaScript API भी है. इसका इस्तेमाल, लोकल XSLT स्टाइलशीट के साथ लोकल एक्सएमएल दस्तावेज़ों को प्रोसेस करने के लिए किया जा सकता है.
XSLT का इतिहास
वर्ल्ड वाइड वेब कंसोर्टियम (W3C) ने 16 नवंबर, 1999 को XSLT को XML दस्तावेज़ों को अन्य फ़ॉर्मैट में बदलने के लिए एक भाषा के तौर पर इस्तेमाल करने का सुझाव दिया था. आम तौर पर, वेब ब्राउज़र में दिखाने के लिए, XML दस्तावेज़ों को HTML में बदला जाता है. आधिकारिक तौर पर 1.0 वर्शन के सुझाव से पहले, Microsoft ने Internet Explorer 5.0 में W3C के वर्किंग ड्राफ़्ट के आधार पर, मालिकाना हक वाला एक वर्शन उपलब्ध कराया था. इसे मार्च 1999 में रिलीज़ किया गया था. आधिकारिक स्टैंडर्ड के मुताबिक, Mozilla ने साल 2000 के आखिर में Netscape 6 में नेटिव XSLT 1.0 सपोर्ट लागू किया. Safari, Opera, और Chrome के बाद के वर्शन जैसे अन्य मुख्य ब्राउज़र में भी, नेटिव XSLT 1.0 प्रोसेसर शामिल किए गए. इससे, क्लाइंट-साइड XML-to-HTML ट्रांसफ़ॉर्मेशन, साल 2000 की शुरुआत में एक अहम वेब टेक्नोलॉजी बन गई.
XSLT भाषा में समय के साथ बदलाव होते रहे. XSLT 2.0 को 2007 और XSLT 3.0 को 2017 में रिलीज़ किया गया. इनमें रेगुलर एक्सप्रेशन, बेहतर डेटा टाइप, और JSON को प्रोसेस करने की सुविधा जैसी कई नई सुविधाएं जोड़ी गईं. हालांकि, ब्राउज़र के लिए सहायता उपलब्ध नहीं कराई गई. आज, सभी मुख्य वेब ब्राउज़र इंजन सिर्फ़ 1999 के ओरिजनल XSLT 1.0 के साथ काम करते हैं. इस वजह से, क्लाइंट-साइड XSLT का इस्तेमाल काफ़ी कम हो गया है. इसकी वजह यह है कि JSON का इस्तेमाल वायर फ़ॉर्मैट के तौर पर बढ़ गया है. साथ ही, JavaScript लाइब्रेरी और फ़्रेमवर्क (जैसे, jQuery, React, और Vue.js) का इस्तेमाल भी बढ़ गया है. ये लाइब्रेरी और फ़्रेमवर्क, DOM में बदलाव करने और टेंप्लेट बनाने के लिए ज़्यादा बेहतर और असरदार सुविधाएं देते हैं. वेब ब्राउज़र में इसकी भूमिका को, JavaScript पर आधारित इन टेक्नोलॉजी ने काफ़ी हद तक बदल दिया है.
XSLT को क्यों हटाया जाना चाहिए?
वेब ब्राउज़र में XSLT 1.0 का इस्तेमाल जारी रखने से, सुरक्षा से जुड़ा गंभीर और गैर-ज़रूरी जोखिम पैदा होता है. इन बदलावों को प्रोसेस करने वाली लाइब्रेरी, जैसे कि libxslt (Chromium ब्राउज़र इसका इस्तेमाल करते हैं), जटिल और पुराने C/C++ कोडबेस हैं. इस तरह के कोड में, मेमोरी से जुड़ी सुरक्षा की गड़बड़ियां होने का खतरा ज़्यादा होता है. जैसे, बफ़र ओवरफ़्लो. इनकी वजह से, आर्बिट्रेरी कोड को एक्ज़ीक्यूट किया जा सकता है. उदाहरण के लिए, सुरक्षा ऑडिट और बग ट्रैकर ने इन पार्सर में बार-बार गंभीर जोखिमों की पहचान की है. जैसे, CVE-2025-7425 और CVE-2022-22834, दोनों libxslt में मौजूद हैं). क्लाइंट-साइड XSLT अब एक खास सुविधा है, जिसका इस्तेमाल बहुत कम किया जाता है. इसलिए, इन लाइब्रेरी का रखरखाव और सुरक्षा जांच, मुख्य JavaScript इंजन की तुलना में बहुत कम होती है. हालांकि, ये गैर-भरोसेमंद वेब कॉन्टेंट को प्रोसेस करने के लिए, सीधे तौर पर एक खतरनाक हमला करने की जगह का काम करती हैं. दरअसल, XSLT की वजह से हाल ही में सुरक्षा से जुड़े कई गंभीर जोखिम सामने आए हैं. इनसे ब्राउज़र का इस्तेमाल करने वाले लोगों को अब भी खतरा बना हुआ है. इस पुरानी सुविधा को बनाए रखने से सुरक्षा से जुड़े जोखिम, इसकी सीमित आधुनिक उपयोगिता से कहीं ज़्यादा हैं.
इसके अलावा, क्लाइंट-साइड XSLT का मूल मकसद, डेटा को रेंडर किए जा सकने वाले एचटीएमएल में बदलना था. हालांकि, अब इसकी जगह ज़्यादा सुरक्षित, इस्तेमाल में आसान, और बेहतर तरीके से रखरखाव किए जाने वाले JavaScript एपीआई ने ले ली है. मॉडर्न वेब डेवलपमेंट, डेटा (आम तौर पर JSON) को वापस पाने के लिए Fetch API और XML या एचटीएमएल स्ट्रिंग को ब्राउज़र के सुरक्षित JavaScript सैंडबॉक्स में DOM स्ट्रक्चर में सुरक्षित तरीके से पार्स करने के लिए DOMParser API जैसी चीज़ों पर निर्भर करता है. इसके बाद, React, Vue, और Svelte जैसे फ़्रेमवर्क, इस डेटा को बेहतर तरीके से और सुरक्षित तरीके से रेंडर करते हैं. इस मॉडर्न टूलचेन को लगातार डेवलप किया जा रहा है. साथ ही, JavaScript इंजन में सुरक्षा से जुड़े बड़े निवेश का फ़ायदा मिलता है. इसके अलावा, आज के समय में लगभग सभी वेब डेवलपर इसका इस्तेमाल करते हैं. दरअसल, आज सिर्फ़ 0.02% वेबपेज लोड करने के लिए XSLT का इस्तेमाल किया जाता है. साथ ही, 0.001% से भी कम वेबपेज, XSLT प्रोसेसिंग के निर्देशों का इस्तेमाल करते हैं.
यह कार्रवाई सिर्फ़ Chrome या Chromium पर नहीं की जा रही है. दो अन्य मुख्य ब्राउज़र इंजन भी वेब प्लैटफ़ॉर्म से XSLT हटाने की सुविधा देते हैं: WebKit, Gecko.
इन वजहों से, XSLT को बंद करने और हटाने से, सभी उपयोगकर्ताओं के लिए ब्राउज़र के अटैक सरफेस को कम किया जा सकता है. साथ ही, वेब प्लैटफ़ॉर्म को आसान बनाया जा सकता है. इसके अलावा, इंजीनियरिंग संसाधनों को उन टेक्नोलॉजी को सुरक्षित करने पर फ़ोकस करने की अनुमति दी जा सकती है जो असल में मॉडर्न वेब को पावर देती हैं. इससे डेवलपर को कोई नुकसान नहीं होता.
एक्सएमएल पार्सिंग की सुरक्षा को बेहतर बनाना
libxslt में सुरक्षा से जुड़ी गंभीर समस्याओं की तरह ही, हाल ही में libxml2 में भी गंभीर सुरक्षा समस्याओं की शिकायतें मिली हैं. libxml2 का इस्तेमाल Chromium में एक्सएमएल को पार्स करने, क्रम से लगाने, और उसकी जांच करने के लिए किया जाता है. Chromium में एक्सएमएल पार्स करने से जुड़ी सुरक्षा की आने वाली समस्याओं को हल करने के लिए, हम libxml2 का इस्तेमाल बंद करने का प्लान बना रहे हैं. साथ ही, एक्सएमएल पार्स करने की सुविधा को, Rust में लिखी गई मेमोरी-सेफ़ एक्सएमएल पार्सिंग लाइब्रेरी से बदलने का प्लान बना रहे हैं. अहम बात यह है कि हम ब्राउज़र से XML को नहीं हटाएंगे. यहां सिर्फ़ XSLT को हटाने पर विचार किया जा रहा है. हम यह पक्का करना चाहते हैं कि libxml2 को बदलने की प्रोसेस, वेब डेवलपर के लिए पूरी तरह से पारदर्शी हो.
माइग्रेट करने का तरीका
माइग्रेट करने के कुछ अन्य तरीके भी हैं.
JSON
जिन साइटों को पूरी तरह से एक्सएमएल और एक्सएसएल पर बनाया गया है उन्हें माइग्रेट करने का कोई एक तरीका नहीं है. माइग्रेट करने के विकल्पों में, XSLT प्रोसेसिंग पाइपलाइन को सर्वर साइड पर ले जाना और रेंडर किए गए एचटीएमएल को क्लाइंट को भेजना शामिल है. इसके अलावा, सर्वर-साइड एक्सएमएल एपीआई एंडपॉइंट को JSON पर माइग्रेट करना और JavaScript का इस्तेमाल करके क्लाइंट-साइड रेंडरिंग करना भी शामिल है. इससे JSON को एचटीएमएल DOM और सीएसएस में बदला जा सकता है.
JavaScript में क्लाइंट-साइड XSLT
क्लाइंट-साइड (JavaScript पर आधारित) XSLT की कुछ लाइब्रेरी उपलब्ध हैं. हालांकि, सबसे बड़ी लाइब्रेरी Saxonica ने बनाई है. Saxonica के बारे में पूरी जानकारी देने वाला दस्तावेज़ देखें. यह वेब ब्राउज़र में XSLT 1.0 को लागू करने से कहीं ज़्यादा बेहतर है. इसमें v3.0 स्टैंडर्ड के लिए पूरी तरह से सपोर्ट उपलब्ध है. साथ ही, v4.0 स्टैंडर्ड के लिए भी सपोर्ट उपलब्ध है.
पॉलीफ़िल
एक polyfill है. यह XSLT 1.0 के वेब ब्राउज़र के वर्शन पर निर्भर करने वाले मौजूदा कोड को काम करने की अनुमति देता है. हालांकि, यह ब्राउज़र की नेटिव XSLT सुविधाओं का इस्तेमाल नहीं करता. पॉलीफ़िल GitHub पर मौजूद है.
polyfill में XSLTProcessor क्लास के लिए, WASM पर आधारित polyfilled रिप्लेसमेंट शामिल होता है. इसलिए, मौजूदा JavaScript कोड पहले की तरह काम कर सकता है:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
पॉलीफ़िल, एक्सएसएलटी प्रोसेसिंग निर्देशों का इस्तेमाल करने वाले एक्सएमएल दस्तावेज़ों को आसानी से बदलने के लिए, अपने-आप काम करने वाला यूटिलिटी फ़ंक्शन भी उपलब्ध कराता है:
इस तरह की ओरिजनल 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> एलिमेंट, पॉलीफ़िल लोड करता है. यह एक्सएमएल दस्तावेज़ के टाइप और XSLT प्रोसेसिंग के निर्देश का पता लगाता है. साथ ही, दस्तावेज़ को बदलकर उसे पारदर्शी तरीके से लोड करता है.
Extension
Chrome एक्सटेंशन भी उपलब्ध है. इसे उन ब्राउज़र में जोड़ा जा सकता है जिन पर यह काम करता है. यह एक्सटेंशन, XSLT प्रोसेसिंग के निर्देशों या XSLTProcessor को कॉल करने वाले सभी रॉ एक्सएमएल पेजों पर एक ही XSLT पॉलीफिल लागू करेगा. इसका इस्तेमाल उन ऐप्लिकेशन के लिए किया जा सकता है जहां सोर्स XML या XSLT को बदला नहीं जा सकता, ताकि फ़ंक्शन काम करते रहें.
खास तौर पर, जब XSLT बंद होता है, तब Chrome अब एक चेतावनी बैनर दिखाता है. यह बैनर, एक्सटेंशन के खोज पेज से सीधे तौर पर लिंक होता है, ताकि उपयोगकर्ताओं को एक्सटेंशन ढूंढने में मदद मिल सके:
इस्तेमाल के खास उदाहरण
एचटीएमएल स्टैंडर्ड पर हुई चर्चा में, इस्तेमाल के कई उदाहरणों की पहचान की गई. इस सेक्शन में, इन सभी के बारे में खास तौर पर बताया गया है. इससे उन डेवलपर को आगे बढ़ने के तरीके सुझाए जा सकते हैं जो आज XSLT का इस्तेमाल करने वाली XML संसाधन फ़ाइलें पब्लिश कर रहे हैं.
आरएसएस और ऐटम फ़ीड
कई मौजूदा आरएसएस या ऐटम फ़ीड में, XSLT का इस्तेमाल किया जाता है. इससे ब्राउज़र में सीधे तौर पर देखने पर, रॉ एक्सएमएल फ़ीड को आसानी से पढ़ा जा सकता है. इसका मुख्य इस्तेमाल यह है कि जब कोई व्यक्ति गलती से किसी साइट के आरएसएस फ़ीड लिंक पर क्लिक करता है, तो उसे आरएसएस फ़ीड रीडर में उस लिंक को चिपकाने के बजाय, फ़ॉर्मैट किया गया एचटीएमएल जवाब मिलता है. इसे वह पढ़ सकता है. उसे रॉ एक्सएमएल नहीं मिलता.
इस उदाहरण के लिए, आगे बढ़ने के दो तरीके हैं. इसे करने का "स्टैंडर्ड" एचटीएमएल तरीका यह है कि किसी (एचटीएमएल पर आधारित) साइट में <link rel="alternate" type="application/rss+xml"> जोड़ा जाए. इसके बजाय, साफ़ तौर पर (उपयोगकर्ता को दिखने वाला) <a
href="something.xml"> न जोड़ा जाए, जिस पर उपयोगकर्ता गलती से क्लिक कर सकते हैं. इस समाधान की मदद से, आरएसएस रीडर को फ़ीड ढूंढने की अनुमति मिलती है. ऐसा तब होता है, जब कोई उपयोगकर्ता सिर्फ़ वेबसाइट का यूआरएल चिपकाता है. हालांकि, इससे असली उपयोगकर्ताओं को सामान्य एचटीएमएल कॉन्टेंट देखने की अनुमति भी मिलती है. इससे वे एक्सएमएल संसाधन के लिंक से भ्रमित नहीं होते. यह सामान्य वेब पैराडाइम का भी पालन करता है, जिसमें एचटीएमएल इंसानों के लिए और एक्सएमएल मशीनों के लिए होता है. हालांकि, इससे उस मामले का समाधान नहीं होता है जहां किसी व्यक्ति के पास आरएसएस लिंक है और वह उसे आरएसएस रीडर के बजाय, अपने वेब ब्राउज़र में चिपकाता है.
अगर आपको वह समाधान नहीं चाहिए, तो पॉलीफ़िल एक और तरीका उपलब्ध कराता है. जैसा कि पहले बताया गया है, आरएसएस/ऐटम एक्सएमएल फ़ीड में एक लाइन, <script
src="xslt-polyfill.min.js"
xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script>, जोड़ी जा सकती है. इससे, एक्सएसएलटी पर आधारित एचटीएमएल में बदलाव करने का मौजूदा तरीका बना रहेगा.
इससे आरएसएस रीडर की, एक्सएमएल को पार्स करने की क्षमता पर कोई असर नहीं पड़ना चाहिए. ऐसा इसलिए, क्योंकि <script> रूट एलिमेंट का डायरेक्ट चाइल्ड है.
एम्बेड किए गए डिवाइसों के लिए एपीआई आउटपुट
कारोबार के लिए इस्तेमाल किए जाने वाले कुछ एम्बेड किए गए डिवाइस, स्थानीय नेटवर्क पर उपयोगकर्ताओं के इस्तेमाल के लिए XML डेटा को मेज़र करते हैं या जनरेट करते हैं. इनमें से कुछ डिवाइस, एक एक्सएमएल डेटा फ़ीड जनरेट करके ऐसा करते हैं. यह फ़ीड, XSLT का इस्तेमाल करके इसे ऐसे एचटीएमएल फ़ॉर्मैट में बदलता है जिसे आसानी से पढ़ा जा सकता है. इससे एपीआई को सीधे तौर पर ब्राउज़र में देखा जा सकता है. इसके लिए, डिवाइस या ब्राउज़र में कोई अतिरिक्त कोड जोड़ने की ज़रूरत नहीं होती.
यह ऐप्लिकेशन के हिसाब से इस्तेमाल का एक खास उदाहरण है. इसलिए, समाधान का तरीका अलग-अलग हो सकता है. जिन ऐप्लिकेशन में एम्बेड किए गए डिवाइस के सोर्स कोड को अपडेट किया जा सकता है उनके लिए, ऊपर बताए गए किसी भी विकल्प (JSON, Polyfill) का इस्तेमाल किया जा सकता है. हालांकि, खास तौर पर ऐसे कई डिवाइसों को अपडेट करना मुश्किल या नामुमकिन होता है. इसकी कई वजहें हो सकती हैं. ऐसे में, एक्सटेंशन सबसे अच्छा विकल्प है. इसकी वजह यह है कि यह क्लाइंट ब्राउज़र को डिवाइस में बदलाव किए बिना, डेटा को ठीक उसी तरह से पढ़ने की अनुमति देता है.
वेबसाइटों के लिए लेज़ी टेंप्लेटिंग
वेब डेवलपर कभी-कभी क्लाइंट साइड पर XSLT का इस्तेमाल करते हैं, ताकि वे सिमैंटिक मार्कअप पर प्रज़ेंटेशन मार्कअप लागू कर सकें. यह लेज़ी टेंप्लेटिंग लैंग्वेज के तौर पर काम करता है और JavaScript इकोसिस्टम से अलग होता है.
इस सामान्य समस्या को हल करने के दो तरीके हैं. इस तरह से बनाई गई किसी मौजूदा साइट के लिए, मौजूदा फ़ंक्शन को बनाए रखने का सबसे आसान तरीका यह है कि उसमें पॉलीफ़िल जोड़ दिया जाए. इसके अलावा, सर्वर साइड पर XSLT ट्रांसफ़ॉर्मेशन किया जा सकता है. साथ ही, क्लाइंट को रॉ एक्सएमएल के बजाय, नतीजे के तौर पर मिले एचटीएमएल को उपलब्ध कराया जा सकता है. इस तरह की प्रॉपर्टी के लिए, लंबे समय तक काम करने वाला समाधान यह होगा कि उन्हें ज़्यादा आधुनिक JavaScript या JSON पर आधारित फ़्रेमवर्क पर माइग्रेट किया जाए.