- वैकल्पिक स्पेसिफिकेशन का लक्ष्य पूरे Web को नहीं, बल्कि 6 मई 2026 के अनुसार 18.3MiB अनकम्प्रेस्ड आकार वाली HTML स्पेसिफिकेशन को प्राथमिक लक्ष्य बनाना है, ताकि Web की खूबियाँ बनी रहें और उसकी कमियों से बचा जा सके
- स्पेसिफिकेशन छोटी और सरल होनी चाहिए, और पूरे स्पेसिफिकेशन वाले compressed
tar.gz को 1.44MiB तक सीमित करने जैसे तरीके से implementation burden कम किया जाना चाहिए, ताकि कई तरह के browser और client बन सकें
- यह मौजूदा Web specification की तरह लगातार बदलने वाला दस्तावेज़ नहीं, बल्कि
1.2.3 जैसे semantic version वाला होना चाहिए, और प्रकाशित standard version कभी भी बदली नहीं जानी चाहिए
- स्पेसिफिकेशन में आसानी से parse की जा सकने वाली unambiguous formal grammar शामिल होनी चाहिए, और standard का पालन न करने वाले pages को render नहीं किया जाना चाहिए, ताकि parser और content tools बनाने की लागत कम हो
- वैकल्पिक स्पेसिफिकेशन का लक्ष्य feature-by-feature Web replication नहीं, बल्कि लिखित text पर केंद्रित information exchange है, और scripting की जगह Geo link या tiled web map standard जैसे standardized file·URL को native program में खोलने के तरीके को प्राथमिकता दी जाती है
वेब के वैकल्पिक स्पेसिफिकेशन का लक्ष्य
- 6 मई 2026 के अनुसार HTML स्पेसिफिकेशन का uncompressed आकार 18.3MiB है, और प्राथमिक समीक्षा का दायरा पूरे Web के बजाय HTML स्पेसिफिकेशन तक सीमित है
- लक्ष्य ऐसा वैकल्पिक स्पेसिफिकेशन बनाना है जो Web की खूबियों को यथासंभव बनाए रखे और उसकी कमियों से बचे
- यह अभी औपचारिक स्पेसिफिकेशन नहीं है, बल्कि समय के साथ बदल सकने वाले अनौपचारिक नोट्स के अधिक करीब है
सरलता और implementation की विविधता
- पूरा स्पेसिफिकेशन छोटा और सरल होना चाहिए, और कम प्रयास में विभिन्न browser और client बनाए जा सकें, ऐसा होना चाहिए
- कई दशकों तक सरलता बनाए रखना बहुत कठिन है, इसलिए स्पेसिफिकेशन की लंबाई को byte स्तर पर सीमित करने वाला नियम एक तरीका हो सकता है
- Dillo अपने release को एक single floppy disk में समेटने के लिए यही तरीका इस्तेमाल करता है, और वैकल्पिक स्पेसिफिकेशन में भी पूरे स्पेसिफिकेशन वाले compressed
tar.gz के लिए 1.44MiB की सीमा रखी जा सकती है
semantic version management
- मौजूदा Web specification लगभग हर हफ्ते बदलने वाला page है, इसलिए किसी client को स्पेसिफिकेशन का पालन करना हो तो उसे लगातार बदलावों का पीछा करना पड़ता है
- वैकल्पिक स्पेसिफिकेशन में
1.2.3 जैसा सटीक semantic version होना चाहिए
1.2.3 दस्तावेज़ 1.2.3, 1.2.0, 1.3.0 को support करने वाले browser में सही render हो सकता है, लेकिन केवल 1.1.0 या 2.0.0 को support करने वाले browser में नहीं — इस तरह के compatibility criteria की आवश्यकता है- दस्तावेज़ लिखने का लक्ष्य browser-वार implementation status नहीं, बल्कि standard version होना चाहिए; उदाहरण के लिए, अगर यह माना जाए कि 90% browser
1.2.0 standard को support करते हैं, तो उसी version को लक्ष्य बनाकर लिखा जा सकता है
- एक बार प्रकाशित standard version को कभी भी बदला नहीं जाना चाहिए
- typo fixes को patch version बढ़ाकर संभाला जाए
- backward-compatible नए features को minor version बढ़ाकर संभाला जाए
- compatibility तोड़ने वाले बदलावों के लिए major version बढ़ाना आवश्यक हो
- केवल
1.2.0 standard की printed copy होने पर भी एक isolated environment में पूरी तरह compliant browser बनाया जा सके, और वह browser स्थायी रूप से 1.2.X दस्तावेज़ों को सही parse कर सके
सख्त grammar
- स्पेसिफिकेशन में आसानी से parse की जा सकने वाली unambiguous formal grammar शामिल होनी चाहिए
- pages को standard के विरुद्ध test किया जाना चाहिए और compliance का निर्णय मिलना चाहिए; जो pages compliant न हों उन्हें render नहीं किया जाना चाहिए
- client द्वारा स्पेसिफिकेशन का पालन न करने वाले pages को स्वीकार करना स्पष्ट रूप से निषिद्ध होना चाहिए
- broken pages को ठीक करने के लिए जटिल standardized rules implement करने की ज़रूरत नहीं होगी, और इससे स्पेसिफिकेशन की गलतियों को बाद के version में ठीक करने के लिए मजबूरी भी बनेगी
- सख्त grammar लोगों को ऐसे अधिक lenient language की ओर ले जा सकती है जिन्हें लिखना आसान हो, जैसे Markdown; यह एक इच्छित प्रभाव है
- लक्ष्य parser को सरल बनाना और content को manipulate करने वाले tools बनाने की लागत घटाना है
- patch version में बदलाव केवल wording बदलें, grammar वही रहे
HTML के पुन: उपयोग की संभावना
- अगर मौजूदा software में न्यूनतम प्रयास से काम करने वाला HTML का subset बनाया जा सके तो यह वांछनीय होगा
- हालांकि HTML parsing की जटिलता के कारण यह संभव न भी हो सके
- XML document की formal grammar बनाना भी सरल नहीं है, इसलिए यह जाँचने की ज़रूरत है कि HTML/XML सरल parsing के लिए उपयुक्त format हैं या नहीं
standard capture के प्रति प्रतिरोध
- Web की एक समस्या यह है कि जब किसी monopolistic entity के लिए revenue extraction mechanism बनाना संभव हो जाता है, तो उसके पास standard को अपने हित में capture कर बदलने की प्रेरणा पैदा होती है
- Web में इसके परिणामस्वरूप standard की जटिलता अनियंत्रित रूप से बढ़ी, नए browser के लिए entry barrier ऊँचा हुआ, और competition कम हुआ — ऐसा माना गया है
- इस स्थिति को रोकने के लिए कुछ शुरुआती विचार हैं, लेकिन game theory के नज़रिये से अधिक सावधानीपूर्ण समीक्षा की ज़रूरत है
text-first सिद्धांत
- स्पेसिफिकेशन का उद्देश्य इतनी detail को कवर करना है जो छपी हुई किताबों या लेखन की तरह मनुष्यों के बीच information transfer के लिए पर्याप्त हो
- जानकारी encode करने के लिए लिखित text को सबसे बहुमुखी माध्यम मानकर प्राथमिकता दी जानी चाहिए
- text का अनुवाद किया जा सकता है, उसे computer ज़ोर से पढ़ सकता है, और वह कम storage space में रखा जा सकता है
- दस्तावेज़ों में screen size के अनुसार line breaks होने चाहिए, ताकि वही दस्तावेज़ छोटी और बड़ी दोनों screens पर पढ़ा जा सके
scripting का बहिष्कार
- scripting feature जोड़ना एक गलती थी, इसलिए वैकल्पिक स्पेसिफिकेशन में इससे बचा जा सकता है
- इसका मतलब यह नहीं है कि उपयोगकर्ता interactive programs का उपयोग नहीं कर सकेंगे
- उदाहरण के लिए, आज JavaScript से browser के भीतर point-of-interest location दिखाने वाला interactive map load किया जाता है, लेकिन इसके बजाय Geo link दिया जा सकता है ताकि उस protocol को support करने वाला कोई भी client उस location को खोल सके
- इसी तरह, अगर सार्वजनिक स्पेसिफिकेशन हो तो कोई भी client server के map tiles का उपयोग कर सकता है; संबंधित उदाहरण के रूप में tiled web map standard प्रस्तुत किया गया है
- native program में standardized file या URL खोलने का तरीका इस्तेमाल किए जा रहे device के अनुसार optimize किया जा सकता है, और कई interactive web pages के एकरूप approach से बचा जा सकता है
जो लक्ष्य नहीं हैं
- लक्ष्य Web को feature-by-feature दोहराना नहीं है
- लक्ष्य ऐसी स्पेसिफिकेशन बनाना है जो मनुष्यों को ज्ञान, notes और अन्य जानकारी का आदान-प्रदान करने दे, लेकिन उसे पढ़ने के लिए एक पूर्ण VM चलाने की आवश्यकता को हटा दे
1 टिप्पणियां
Lobste.rs की राय
तो क्या इसका मतलब फिर से यह है कि हर चीज़ के लिए एक app चाहिए? मैं इस बात से सहमत नहीं हूँ कि scripting capability अपने-आप में एक गलती थी
मुझे यह अच्छा लगता है कि web operating system की सीमाओं के पार जाने वाला एक general-purpose platform है
वही समय जब सिर्फ Windows support होता था और कभी-कभी Mac भी जोड़ दिया जाता था
और native desktop development की स्थिति भी आसान नहीं है, इसलिए desktop पर web app या Electron चुनने वालों के प्रति मुझे काफ़ी सहानुभूति है
आधुनिक web की समस्या यह है कि वह concepts को लगातार दोबारा invent करता रहता है, और उनमें से काफ़ी चीज़ें declarative markup होनी चाहिए। website display path में JavaScript के घुसने की ज़रूरत नहीं होनी चाहिए। scripting का इस्तेमाल सिर्फ उन खास client-side programming कामों में होना चाहिए जो पहले server पर होते थे, जैसे server से लौटे dataset को process करना
ऐसा लगता है कि IT industry ने web browser को de facto virtual machine बना दिया, क्योंकि Java और Swing, Flash जैसी sandbox alternatives दर्दनाक रूप से घटिया साबित हुईं। अब Google Chrome नाम की एक single application आम users की अधिकांश general computing के लिए virtual machine का काम कर रही है, और वह भी एक surveillance capitalism monopoly company की मालिकाना और development के तहत। पता नहीं यह सच में ज़्यादा सुरक्षित है, या बस असली zero-day इतने महंगे हो गए हैं कि public नहीं होते
मेरे हिसाब से scripting जोड़ना एक गलती थी। कम-से-कम यह बाद में जोड़ी गई चीज़ थी, और मैं Dillo के इस दायरे से सहमत हूँ कि hypertext document reader का काम documents पढ़ना है, reader के अंदर document creation/editing तक ले जाना नहीं
लक्ष्य यह नहीं होना चाहिए कि web को feature-by-feature copy किया जाए, बल्कि ऐसी spec बनाई जाए जिसे knowledge, notes और information के आदान-प्रदान के लिए full-size virtual machine चलाने की ज़रूरत बिना पढ़ा जा सके
मैं एक बेहतर sandbox के भीतर ज़्यादातर “interaction” की ज़रूरतें संभालने वाला छोटा किया हुआ general-purpose application देखना चाहूँगा। क्या Reddit जैसे social media feed पर hypertext भेजने-लेने के लिए सच में पूरी virtual machine चाहिए? क्या shopping cart और payment information संभालने के लिए भी पूरी virtual machine चाहिए?
हाँ, यह भी संभव है कि “general-purpose” आख़िरकार “application” को ही निगल जाए, और हम फिर उसी बिंदु पर web को दोबारा invent करने लगें। फिर भी अगर Google के अलावा कोई और, और C++ के अलावा कोई और भाषा इसकी नींव बने, तो शायद यह बेहतर हो। Dillo तो C और C++ में लगता है, तो शायद कम-से-कम एक चीज़ तो बेहतर हुई
एक और सुधार यह हो सकता है कि HTTP का छोटा संस्करण इस्तेमाल किया जाए, लेकिन cookies में सिर्फ client-controlled session cookies की support हो, third-party resources पर रोक हो, और सभी resources उसी web server पर हों जिस पर document है, साथ ही browser के अंदर के converters से text/markdown जैसे formats render कराने की शर्त हो
इस बार मेरा रुख यह है कि design इतना सुधारा जाए कि cookies से बचा जा सके। यह document का machine representation है; इसे इंसानों द्वारा पढ़े जाने लायक बनाया गया है, लेकिन इंसानों के सीधे लिखने के लिए नहीं। उसकी जगह Markdown जैसी frontend language इस्तेमाल हो और उसे compile करके portable, strict document बनाया जाए
example.netकी cookiesub.example.netको न भेजी जाए, औरsub.example.netकी cookie भीexample.netपर set न होHTTP/2 और HTTP/3 application web के लिए छोड़ देना चाहिए, और HTTP/1 document web के लिए रखना चाहिए। JavaScript को कैसे सीमित किया जाए ताकि “मेरा content देखने के लिए तुम्हें एक dedicated browser चाहिए” वाली समस्या न आए, यह मुझे नहीं पता, इसलिए JavaScript ही नहीं होनी चाहिए
अगर text/markdown rendering अनिवार्य की जाए, तो यह भी सवाल है कि किस version की बात हो रही है। support करने लायक variants लगभग आधा दर्जन हैं
strict grammar शायद काम नहीं करेगी। XHTML के fail होने की वजह भी यही थी, और HTML5 ने आम “broken” cases को handle करने के rules इसी कारण जोड़े
लेखक की इच्छा के मुताबिक HTML5 को एक अधिक formal grammar में दोबारा specify किया जा सकता है, लेकिन pages को सख्ती से reject करना fork का अच्छा इस्तेमाल नहीं लगता। दूसरा विकल्प फिर किसी और gopher/gemini substitute जैसा बन जाना है, और उसके niche fanbase के बावजूद उसके लोकप्रिय न होने की वजहें हैं। backward compatibility की ताकत बहुत ज़्यादा है
strictness बहुत अच्छी हो सकती है, लेकिन उसके लिए support होना ज़रूरी है
“scripting capability जोड़ना एक गलती थी” यह विचार उन उदास programmer types के बीच पुराना meme रहा है जो fun की इजाज़त नहीं देते, लेकिन मुझे यह ज़्यादा imagination की कमी जैसा लगता है
सोच-समझकर लागू किया गया interactive multimedia communication और explanation को बहुत बेहतर बना सकता है। उदाहरण के लिए Red Blob Games Hex-Grid tutorial के interactive diagrams या Bartosz Ciechanowski's fantastic explanation of mechanical watch movement को देखिए। web के interactive media की वजह से Canon Cat जैसे ऐतिहासिक रूप से महत्वपूर्ण rare computer को भी native emulator compile और run करने की डरावनी प्रक्रिया के बिना सिर्फ कुछ clicks में आज़माया जा सकता है। form submission और image maps तो multimedia की बहुत ही फीकी छाया भर हैं, और interaction support का बोझ एक मूलतः server-centric और संभवतः bandwidth-heavy model पर डालते हैं
समस्या scripting behavior खुद नहीं है, समस्या यह है कि मौजूदा browser में script को क्या-क्या करने की अनुमति है। जिस तरह HTTP और HTML को छोटा, सरल और user autonomy का सम्मान करने वाला सिस्टम बनाया जा सकता है, उसी तरह web JavaScript की ज़्यादातर अच्छी बातें रखते हुए उसकी API surface और दुरुपयोग की संभावना बहुत घटाई जा सकती है। उदाहरण के लिए, आप ऐसे web की कल्पना कर सकते हैं जिसमें page के अंदर Flash जैसी कोई interactive rectangle हो, interaction user-accessible और inspectable Lua scripts तथा Love2D जैसी graphics/input capabilities से दिया जाए, जबकि remote server से संपर्क करना या webcam access जैसी privacy-invasive चीज़ें मजबूत sandbox और user की साफ़, पहले से दी गई सहमति के पीछे रखी जाएँ
आज भी इस तरह की सम्मानजनक web applications बनाई जा सकती हैं, लेकिन इसका आधार ऊबड़-खाबड़, असंगत, और जगह-जगह उपयोगी features की स्पष्ट कमी तथा user safety/privacy के लिए अनावश्यक ख़तरों से भरा है
accessibility के नज़रिए से एक vision यह हो सकता है कि button, field, checkbox, slider जैसी declarative UI inputs को सख्ती से handle किया जाए, और client-side forms को static page की तरह
<iframe>के अंदर image और markup render करते हुए remote server round-trip के बिना चलाया जाए। कई calculators, tools और interactive visualizations इस model में आ सकते हैं, और backend-driven model की तुलना में latency और user security दोनों बेहतर होंगेअगर “text-first” चाहिए, तो CSS भी छोड़नी होगी। CSS ज़्यादातर users के लिए नहीं, companies के लिए मौजूद है। style पर control page का नहीं, browser का होना चाहिए
अगर user ने raw page payload पढ़ने का फ़ैसला किया है, तो उसका अधिकांश हिस्सा वही होना चाहिए जो browser उसे पढ़ने के लिए दिखा रहा है। आज पढ़ी जा सकने वाली content तो बस हिमशैल की चोटी है
“no scripting” के मामले में मेरा अनुमान है कि अगर styling और भारी-भरकम pages हट जाएँ, तो display को प्रभावित करने वाली scripting की ज़रूरत भी बहुत कम हो सकती है। और display को प्रभावित न करने वाली scripting अधिकतर user के हित के ख़िलाफ़ ही इस्तेमाल हुई है
लेकिन CSS और formatting ज़रूरत से ज़्यादा जटिल हो गए, और अब user styles को या तो पूरे CSS reset से शुरू करना पड़ता है या site-specific बहुत ही specific होना पड़ता है
मैंने client पर JS के बिना personal tools बनाते हुए यह समस्या झेली, और समझा कि या तो server पर “मेरा timezone setting” रखनी पड़ेगी या कोई छोटा helper script जोड़ना पड़ेगा
अगर styling browser के control में दे दी जाए, तो “मेरा page browser X और Y में पढ़ने लायक है लेकिन Z में नहीं” जैसी समस्याएँ शायद आज से भी बदतर हो जाएँ
मुझे यह उस फीके दस्तावेज़ों की दुनिया से बेहतर लगती है जहाँ लेखक की आवाज़ को सफ़ेद background पर काले text में धो दिया गया हो। CSS web पर लेखक की अभिव्यक्ति का तरीका है, और मैं सच में इसे हटाना नहीं चाहूँगा। यह जटिल है, लेकिन यही complexity और ज़्यादा लोगों को अपनी website पर मज़ेदार चीज़ें करने देती है, इसलिए मेरे लिए यह net positive है
मुझे भी यह एहसास मिलता है कि style और भारी pages हटाने से display बदलने वाले scripts की ज़रूरत कम हो सकती है। अगर कोई सरल grammar हो, तो शायद “documents” को interactive native programs के अंदर embed किया जा सके, उल्टा नहीं
जैसा दूसरे लोग कह रहे हैं, Gemini एक अच्छा reference example है। फिर कहूँगा, Gemini कुछ हद तक performance art जैसा लगता है, लेकिन उससे सच में बहुत कुछ सीखा जा सकता है
Gemini की एक कम-ज्ञात लेकिन ध्यान देने लायक feature है subscribable pages। page के अंदर
YYYY-MM-DDसे शुरू होने वाले text links implicit feed बना देते हैं। यह बहुत सीमित और थोड़ा बेवकूफ़ी भरा लग सकता है, लेकिन मेरे हिसाब से Gemini की सबसे प्रभावशाली features में से एक है। Spec hereपारंपरिक HTML में blog को हाथ से लिखना संभव है। थकाऊ ज़रूर है, पर पूरी तरह संभव है। लेकिन RSS/ATOM feed को maintain करने के लिए लगभग हमेशा feed generation tools चाहिए होते हैं
अगली पीढ़ी के “content-oriented” HTML में ऐसी ही कोई क्षमता होना अच्छा होगा। शायद
h-feedin microformats सही तरीका हो, लेकिन Gemini के subscribable pages वाली सादगी मुझे सच में पसंद है। और हर जगह feeds होना एक अच्छी बात हैGemini का line-based और parse करने में आसान होना बहुत बड़ा फ़ायदा है, लेकिन मुझे लगता है कि यह बहुत सीमित है और accessibility के लिहाज़ से इसके बुरे असर भी हो सकते हैं। फिर भी अगर Gemini जैसा दिखने वाला कोई HTML-lite हो, तो वह ठीक लग सकता है
web fork का एक और फ़ायदा HTML में बाद में चिपकाई गई चीज़ों की सफ़ाई करना होगा।
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>काफ़ी खटकता है। आज जो कुछ हम जानते हैं, उसके आधार पर कोई नया version बनाया जाए तो वह काफ़ी अच्छा हो सकता हैबाक़ी हिस्सों को लेकर मैं कम आश्वस्त हूँ। सिद्धांत रूप से मैं no-JS के पूरी तरह पक्ष में हूँ। लेकिन मैं web का एक सबसे बड़ा उपयोग सरकार, bank जैसी essential services तक universal access को मानता हूँ। अच्छी usability बनाए रखते हुए क्या सच में सब कुछ JS के बिना किया जा सकता है, इस पर अभी पूरी तरह आश्वस्त नहीं हूँ, हालाँकि यह संभव हो सकता है
मैं another comment वाली यह बात भी ज़ोर देकर कहना चाहूँगा कि “यह spec सामान्य web browser में चलने को नहीं रोकती, और आज का web गायब नहीं होने वाला”
अच्छा होगा अगर हम “content web browser” और “app browser” अलग-अलग चला सकें। कई उद्देश्यों के लिए web जितना अच्छा app platform कोई दूसरा विकल्प नहीं है, web बहुत आगे बढ़ चुका है, और developers भी लगता है बाकी चीज़ों की तुलना में web को काफ़ी ज़्यादा पसंद करते हैं
ऐसी दुनिया में Google Maps मेरे content web browser में नहीं चलेगा, बल्कि app browser में खुलेगा। और अगर GMail app browser में चल रहा हो, तो email के अंदर के links content web browser में खुलेंगे
आदर्श रूप से content web browser को implement करना बहुत आसान होना चाहिए, जिससे competition और innovation दोनों बढ़ें। अफ़सोस यह है कि मुझे इसे हासिल करने का रास्ता साफ़ नहीं दिखता। अगर मैं अपनी सारी content browsing ऐसे browser में कर पाता, तो मैं बहुत ज़्यादा ख़ुश होता। attack surface बहुत छोटा हो जाता, इसलिए security के लिहाज़ से भी ज़्यादा सुकून रहता। लेकिन अब लगता है किसी को इसकी परवाह ही नहीं
तो बस उन्हें browser feature के रूप में जोड़ दीजिए
यह Gemini से थोड़ा मिलता-जुलता लगता है, लेकिन यह fork शायद उससे थोड़ा ज़्यादा चीज़ों की अनुमति देगा
मेरा मानना है कि websites को किसी Markdown variant या वैसी किसी चीज़ में लिखा जा सके। document ऐसा होना चाहिए जिसे raw form में भी आसानी से पढ़ा जा सके। यानी Gemtext में inline media जैसी कुछ अतिरिक्त capabilities जोड़ दी जाएँ
और थोड़ी बहुत style capability की भी अनुमति होनी चाहिए। web creative expression के लिए पहले भी शानदार जगह था और आज भी है। अगर एक सरल और सुसंगत style set रखा जाए, तो creative लोग और भी दिलचस्प sites बना सकेंगे
HTMX के मूल तत्वों को भी संबोधित करना अच्छा रहेगा
यह idea तब बेहतर काम करेगा जब इसके पीछे स्पष्ट motivation हो। “इसे simpler बनाओ” बहुत अमूर्त बात है। simplicity हर व्यक्ति के लिए अलग होती है, इसलिए यह ज़्यादा साफ़ लक्ष्य होना चाहिए कि web को सरल क्यों बनाना है और उससे कौन-सी ठोस ज़रूरत पूरी होगी
उदाहरण के लिए Gemini project का फ़ोकस ऐसे community बनाने पर है जो एक खास तरह के communication को महत्व देती है। web को उसी communication form तक सीमित करके simple बनाया गया, क्योंकि वह community के goals के अनुकूल था, और मेरी याद में images तक technically supported नहीं थीं
दूसरी तरफ़ Sciter या Blitz जैसे tools का लक्ष्य दूसरे applications में browser-जैसे renderer को आसानी से embed करना है। ये अनावश्यक quirks हटाकर या HTML parsing और JS execution को optional बनाकर simplification करते हैं। इससे implement करने के लिए भी कम चीज़ें बचती हैं और embed करने वाले users के लिए भी कम बोझ होता है
दोनों ही simplicity को लक्ष्य बनाते हैं, लेकिन क्योंकि उनका मूल लक्ष्य बहुत अलग है, इसलिए नतीजे भी बहुत अलग आते हैं। यहाँ मूल लक्ष्य क्या है?