XML लगभग सधैं दुरुपयोग हुन्छ

XML भाषा 1996 मा आविष्कार गरिएको थियो। यो चाँडै देखा परेको थियो भन्दा पहिले नै यसको आवेदन को संभावनाहरु लाई पहिले नै गलतफहमी हुन थालेको थियो, र उद्देश्यहरु को लागी उनीहरु यसलाई अनुकूलन गर्न कोशिस गर्दै थिए, यो उत्तम विकल्प थिएन।

मैले देखेको XML स्कीमाहरूको विशाल बहुमत XML को अनुपयुक्त वा गलत प्रयोगहरू हुन् भन्नको लागि यो कुनै अतिशयोक्ति छैन। यसबाहेक, XML को यो प्रयोगले XML को बारे मा एक मौलिक गलतफहमी प्रदर्शन गर्यो।

XML एक मार्कअप भाषा हो। यो डाटा ढाँचा होइन। धेरै जसो XML स्कीमाहरूले स्पष्ट रूपमा यो भिन्नतालाई बेवास्ता गरेका छन्, XML लाई डेटा ढाँचासँग भ्रमित गर्दै, जसले अन्ततः XML छनौट गर्दा गल्तीको परिणाम दिन्छ किनभने यो वास्तवमा आवश्यक पर्ने डाटा ढाँचा हो।

धेरै विस्तारमा नजाइकन, संरचना र मेटाडेटाको साथ पाठको ब्लकहरू एनोटेट गर्नको लागि XML सबैभन्दा उपयुक्त छ। यदि तपाईंको मुख्य लक्ष्य पाठको ब्लकसँग काम गर्ने होइन भने, XML छनौट गर्नु उचित हुने सम्भावना छैन।

यस दृष्टिकोणबाट, XML स्कीमा कति राम्रोसँग बनाइएको छ भनी जाँच गर्ने एउटा सरल तरिका हो। उदाहरणको रूपमा अभिप्रेत स्किमामा कागजात लिनुहोस् र यसबाट सबै ट्यागहरू र विशेषताहरू हटाउनुहोस्। यदि बाँकी छ भने कुनै अर्थ छैन (वा यदि त्यहाँ खाली रेखा छ भने), त्यसपछि या त तपाईंको स्कीमा सही रूपमा बनाइएको छैन वा तपाईंले XML प्रयोग गर्नुहुँदैन।

तल म गलत तरिकाले निर्माण गरिएका सर्किटहरूको सबैभन्दा सामान्य उदाहरणहरू दिनेछु।

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

यहाँ हामी XML मा साधारण कुञ्जी-मान शब्दकोश व्यक्त गर्ने निराधार र अनौठो (धेरै सामान्य) प्रयासको उदाहरण देख्छौं। यदि तपाईंले सबै ट्यागहरू र विशेषताहरू हटाउनुभयो भने, तपाईं खाली पङ्क्तिको साथ छोड्नुहुनेछ। अनिवार्य रूपमा, यो कागजात, जतिसुकै बेतुका लागे पनि, खाली रेखाको अर्थपूर्ण एनोटेशन हो।

<root name="John" city="London" />

मामिलाहरूलाई अझ नराम्रो बनाउनको लागि, हामीसँग यहाँ खाली स्ट्रिङको शब्दकोषलाई अभिव्यक्त गर्ने असाधारण तरिकाको रूपमा मात्र छैन - यस पटक "शब्दकोश" लाई मूल तत्वको विशेषताहरूको रूपमा सीधा इन्कोड गरिएको छ। यसले एट्रिब्युट नामहरूको दिइएको सेटलाई तत्वमा अपरिभाषित र गतिशील बनाउँछ। यसबाहेक, यसले देखाउँछ कि सबै लेखक वास्तवमा व्यक्त गर्न चाहन्थे एक साधारण कुञ्जी-मान सिन्ट्याक्स थियो, तर यसको सट्टा उसले XML लागू गर्न एकदमै विचित्र निर्णय गर्यो, एट्रिब्यूट सिन्ट्याक्स प्रयोग गर्न उपसर्गको रूपमा एकल खाली तत्वको प्रयोग गर्न बाध्य पार्दै। र म प्रायः यस्ता योजनाहरू भेट्छु।

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

यो केहि राम्रो छ, तर अब केहि कारणका लागि कुञ्जीहरू मेटाडेटा हुन् र मानहरू छैनन्। शब्दकोशहरूमा धेरै अनौठो नजर। यदि तपाईंले सबै ट्याग र विशेषताहरू हटाउनुभयो भने, आधा जानकारी हराउनेछ।

XML मा एक सही शब्दकोश अभिव्यक्ति यो जस्तो देखिन्छ:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

तर यदि मानिसहरूले XML लाई डेटा ढाँचाको रूपमा प्रयोग गर्ने अनौठो निर्णय गरेका छन् र त्यसपछि यसलाई शब्दावली व्यवस्थित गर्न प्रयोग गर्छन्, तब उनीहरूले के गरिरहेछन् त्यो अनुपयुक्त र सुविधाजनक छैन भनेर बुझ्नुपर्छ। डिजाइनरहरूले आफ्नो एप्लिकेसनहरू सिर्जना गर्न XML लाई गल्तीले रोज्नु पनि सामान्य छ। तर अझ धेरै पटक, तिनीहरूले माथि वर्णन गरिएका फारमहरू मध्ये कुनै एकमा XML को अर्थहीन रूपमा प्रयोग गरेर, XML मात्र यसको लागि उपयुक्त छैन भन्ने तथ्यलाई बेवास्ता गरेर मामिलाहरू खराब बनाउँछन्।

सबैभन्दा खराब XML स्कीमा? वैसे, को लागी पुरस्कार मैले देखेको सबैभन्दा खराब XML स्कीमा, Polycom IP टेलिफोनी फोनहरूको लागि स्वचालित प्रावधान कन्फिगरेसन फाइल ढाँचा प्राप्त गर्दछ। त्यस्ता फाइलहरूलाई TFTP मार्फत XML अनुरोध फाइलहरू डाउनलोड गर्न आवश्यक छ, जुन... सामान्यतया, यहाँ एउटा यस्तो फाइलको अंश हो:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

यो कसैको नराम्रो मजाक होइन। र यो मेरो आविष्कार होइन:

• तत्वहरू केवल विशेषताहरू संलग्न गर्न उपसर्गको रूपमा प्रयोग गरिन्छ, जसको आफ्नै पदानुक्रमिक नामहरू छन्।
• यदि तपाइँ एक विशेष प्रकारको रेकर्डको धेरै उदाहरणहरूमा मानहरू तोक्न चाहनुहुन्छ भने, तपाइँले यो गर्नको लागि विशेषता नामहरू प्रयोग गर्नुपर्छ। जसमा अनुक्रमणिकाहरू छन्.
• थप रूपमा, विशेषताहरू बाट सुरु हुन्छ softkey., तत्वहरूमा राखिएको हुनुपर्छ <softkey/>, बाट सुरु हुने विशेषताहरू feature., तत्वहरूमा राखिएको हुनुपर्छ <feature/> आदि, यो पूर्ण रूपमा अनावश्यक र पहिलो नजरमा अर्थहीन देखिन्छ भन्ने तथ्यको बावजुद।
• र अन्तमा, यदि तपाइँ आशा गर्दै हुनुहुन्थ्यो कि विशेषता नामको पहिलो कम्पोनेन्ट सधैं तत्व नाम जस्तै हुनेछ - त्यस्तो केहि छैन! उदाहरणका लागि, विशेषताहरू up. संलग्न हुनुपर्छ <userpreferences/>। तत्वहरूमा विशेषता नामहरू संलग्न गर्ने क्रम मनमानी छ, लगभग पूर्ण रूपमा।

कागजात वा डाटा। प्रत्येक पटक केहि समय मा, कसैले XML र JSON को तुलना गर्ने प्रयास गरेर पूर्णतया अनौठो कुरा गर्छ - र यसरी तिनीहरूले पनि बुझ्दैनन् भनेर देखाउँछन्। XML कागजात मार्कअप भाषा हो। JSON एक संरचित डेटा ढाँचा हो, त्यसैले तिनीहरूलाई एक अर्कासँग तुलना गर्नु भनेको नरमसँग न्यानो तुलना गर्ने प्रयास गर्नु जस्तै हो।

बीचको भिन्नताको अवधारणा कागजात र डाटा। XML को एनालगको रूपमा, हामी सशर्त रूपमा मेसिन-पढ्न सकिने कागजात लिन सक्छौं। यद्यपि यो मेसिन पढ्न योग्य हुनको लागि हो, यसले कागजातहरूलाई रूपक रूपमा बुझाउँछ, र यस दृष्टिकोणबाट वास्तवमा PDF कागजातहरूसँग तुलना गर्न सकिन्छ, जुन प्राय: मेसिन पढ्न योग्य हुँदैन।

उदाहरणका लागि, XML मा तत्वहरूको क्रम महत्त्वपूर्ण छ। तर JSON मा, वस्तुहरू भित्र कुञ्जी-मान जोडीहरूको क्रम अर्थहीन र अपरिभाषित छ। यदि तपाइँ कुञ्जी-मान जोडीहरूको अक्रमित शब्दकोश प्राप्त गर्न चाहनुहुन्छ भने, त्यो फाइलमा तत्वहरू देखा पर्ने वास्तविक क्रमले फरक पार्दैन। तर तपाईं यस डाटाबाट धेरै फरक प्रकारका डाटा बनाउन सक्नुहुन्छ। कागजातहरूको, किनभने कागजातमा एक निश्चित क्रम छ। रूपक रूपमा, यो कागजमा भएको कागजातसँग मिल्दोजुल्दो छ, यद्यपि यसमा भौतिक आयामहरू छैनन्, प्रिन्टआउट वा PDF फाइलको विपरीत।

उचित XML शब्दकोश प्रतिनिधित्वको मेरो उदाहरणले JSON प्रतिनिधित्वको विपरीत, शब्दकोशमा तत्वहरूको क्रम देखाउँछ। म यो अर्डरलाई बेवास्ता गर्न सक्दिन: यो रेखीयता कागजात मोडेल र XML ढाँचामा अन्तर्निहित छ। केहीले यो XML कागजातको व्याख्या गर्दा अर्डरलाई बेवास्ता गर्न रोज्न सक्छन्, तर यस विषयमा बहस गर्नुको कुनै अर्थ छैन किनकि यो मुद्दा ढाँचाको छलफलको दायराभन्दा बाहिर छ। यसबाहेक, यदि तपाईंले कागजातलाई ब्राउजरमा क्यास्केडिङ स्टाइल पाना जोडेर हेर्न योग्य बनाउनुहुन्छ भने, तपाईंले देख्नुहुनेछ कि शब्दकोश तत्वहरू निश्चित क्रममा देखा पर्छन् र अरू कुनै पनि छैनन्।

अन्य शब्दहरूमा, एक शब्दकोश (संरचित डेटाको टुक्रा) मा रूपान्तरण गर्न सकिन्छ n विभिन्न सम्भावित कागजातहरू (XML, PDF, कागज, आदिमा), जहाँ n - शब्दकोशमा तत्वहरूको सम्भावित संयोजनहरूको संख्या, र हामीले अझै अन्य सम्भावित चरहरूलाई ध्यानमा राखेका छैनौं।

यद्यपि, यसले यो पनि पछ्याउँछ कि यदि तपाइँ केवल डाटा स्थानान्तरण गर्न चाहनुहुन्छ भने, त्यसको लागि मेसिन-पढ्ने कागजात प्रयोग गरेर प्रभावकारी हुनेछैन। यसले एक मोडेल प्रयोग गर्दछ, जुन यस अवस्थामा अनावश्यक छ; यो केवल बाटोमा प्राप्त हुनेछ। थप रूपमा, स्रोत डेटा निकाल्नको लागि, तपाईंले प्रोग्राम लेख्नु पर्छ। कुनै बिन्दुमा कागजातको रूपमा ढाँचामा नपर्ने कुनै चीजको लागि XML प्रयोग गर्नुमा सायद कुनै बिन्दु छैन (भन्नुहोस्, CSS वा XSLT, वा दुबै प्रयोग गरेर), किनकि त्यसो गर्नुको मुख्य (यदि मात्र होइन) कारण हो। कागजात मोडेलमा।

यसबाहेक, XML मा संख्याहरूको कुनै अवधारणा (वा बुलियन अभिव्यक्ति, वा अन्य डेटा प्रकारहरू) नभएको कारणले, यस ढाँचामा प्रतिनिधित्व गरिएका सबै सङ्ख्याहरूलाई मात्र अतिरिक्त पाठ मानिन्छ। डाटा निकाल्नको लागि, स्कीमा र यसको सम्बन्धित डाटासँगको सम्बन्ध थाहा हुनुपर्छ। तपाइँले यो पनि जान्न आवश्यक छ कि कहिले, सन्दर्भमा आधारित, एक विशेष पाठ तत्वले संख्या प्रतिनिधित्व गर्दछ र संख्यामा रूपान्तरण गर्नुपर्छ, आदि।

यसैले, XML कागजातहरूबाट डाटा निकाल्ने प्रक्रिया स्क्यान गरिएका कागजातहरू समावेश गर्ने प्रक्रियाबाट धेरै फरक छैन, उदाहरणका लागि, संख्यात्मक डेटाका धेरै पृष्ठहरू बनाउने तालिकाहरू। हो, यो सिद्धान्तमा यो गर्न सम्भव छ, तर यो सबैभन्दा इष्टतम तरिका होइन, अन्तिम उपायको रूपमा बाहेक, जब त्यहाँ कुनै अन्य विकल्पहरू छैनन्। एक उचित समाधान भनेको मूल डाटाको डिजिटल प्रतिलिपि फेला पार्नु हो जुन कागजात मोडेलमा इम्बेड गरिएको छैन जसले डाटालाई यसको विशिष्ट पाठ्य प्रतिनिधित्वसँग जोड्दछ।

त्यसले भन्यो, यसले मलाई अचम्म मान्दैन कि XML व्यवसायमा लोकप्रिय छ। यसको कारण ठ्याक्कै यो हो कि कागजातको ढाँचा (कागजमा) व्यापारको लागि बुझ्न योग्य र परिचित छ, र तिनीहरू परिचित र बुझ्ने मोडेल प्रयोग गर्न जारी राख्न चाहन्छन्। उही कारणका लागि, व्यवसायहरूले प्राय: अधिक मेसिन-पढ्न सकिने ढाँचाहरूको सट्टा PDF कागजातहरू प्रयोग गर्छन् - किनभने तिनीहरू अझै पनि एक विशिष्ट भौतिक आकारको साथ मुद्रित पृष्ठको अवधारणामा बाँधिएका छन्। यो कागजातहरूमा पनि लागू हुन्छ जुन कहिल्यै छापिने सम्भावना छैन (उदाहरणका लागि, रजिस्ट्री कागजातको 8000-पृष्ठ PDF)। यस दृष्टिकोणबाट, व्यापारमा XML को प्रयोग अनिवार्य रूपमा skeuomorphism को एक अभिव्यक्ति हो। मानिसहरूले सीमित आकारको मुद्रित पृष्ठको रूपक विचार बुझ्छन्, र उनीहरूले छापिएका कागजातहरूमा आधारित व्यापार प्रक्रियाहरू कसरी सिर्जना गर्ने भनेर बुझ्छन्। यदि त्यो तपाईंको गाइड हो भने, भौतिक आकारको सीमाविनाका कागजातहरू जुन मेसिन-पढ्न योग्य छन्—XML कागजातहरू — परिचित र सहज कागजात समकक्ष हुँदा नवाचारलाई प्रतिनिधित्व गर्दछ। यसले तिनीहरूलाई डेटा प्रस्तुत गर्ने गलत र अत्यधिक स्क्युओमोर्फिक तरिकाबाट रोक्दैन।

आज सम्म, केवल XML स्कीमाहरू जुन मलाई थाहा छ कि म साँच्चै ढाँचाको वैध प्रयोगलाई कल गर्न सक्छु XHTML र DocBook।

स्रोत: www.habr.com