इस प्रकार के पार्सर के लिए नाम, या यह मौजूद क्यों नहीं है


27

परम्परागत पार्सर अपने पूरे इनपुट का उपभोग करते हैं और एक एकल पार्स ट्री का उत्पादन करते हैं। मैं एक की तलाश कर रहा हूं जो एक सतत स्ट्रीम का उपभोग करता है और एक पार्स वन का उत्पादन करता है [ संपादित करें: टिप्पणियों में चर्चा देखें कि इस शब्द का उपयोग अपरंपरागत क्यों हो सकता है ]। मेरी आंत कहती है कि मैं इस तरह के पार्सर की जरूरत (या मुझे लगता है कि जरूरत है) के लिए पहला व्यक्ति नहीं हो सकता है , लेकिन मैंने महीनों तक बिना किसी लाभ के खोज की है।

मैं मानता हूं कि मुझे XY समस्या से निजात दिलाई जा सकती है। मेरा अंतिम उद्देश्य पाठ की एक धारा को पार्स करना है, इसमें से अधिकांश को अनदेखा करना और मान्यता प्राप्त वर्गों से पार्स पेड़ों की एक धारा का उत्पादन करना है।

तो मेरा प्रश्न सशर्त है: यदि इन विशेषताओं वाले पार्सरों का एक वर्ग मौजूद है, तो इसे क्या कहा जाता है? और यदि नहीं, तो क्यों? विकल्प क्या है? शायद मुझे किसी तरह की याद आ रही है, मैं पारंपरिक पारस वही कर सकता हूँ जो मैं चाहता हूँ।


1
मूल रूप से आपका पार्सर एक एकल दस्तावेज़ को पार्स करता है और एक पार्स ट्री की पैदावार करता है, फिर तुरंत दूसरे दस्तावेज़ को पार्स करना शुरू कर देता है, मुझे लगता है कि यह व्यवहार संशोधन एकल दस्तावेज़ पर लागू किए गए पार्सिंग तकनीकों की विविधता की तुलना में तुच्छ है। इसलिए इसके लिए एक विशेष शब्द की कमी है।
9000

3
मैंने "पार्स फ़ॉरेस्ट" के लिए एक Google खोज की और पाया कि अर्ली पार्सर उन्हें पैदा करता है।
रॉबर्ट हार्वे

7
क्या आप संभवतः मोनैडिक पार्सर कॉम्बिनेटरों की तलाश कर रहे हैं - अर्थात, एक बड़ा पार्सर जो कई छोटे पार्सरों से बना है। वे उन परिस्थितियों के लिए काम करते हैं जहां एक भाषा का "द्वीप" दूसरे में अंतर्निहित है। C # डिज़ाइन टीम पर मेरे पूर्व सहयोगी ल्यूक होबन का उन पर एक अच्छा लेख है: blogs.msdn.com/b/lukeh/archive/2007/08/19/…/
एरिक

3
कुछ भ्रम है। क्या आपका मतलब है कि आप अपनी धारा में प्रत्येक दस्तावेज़ के लिए एक पार्स ट्री चाहते हैं, और वे एक साथ एक पार्स वन बनाते हैं। यह पार्स वन का सामान्य अर्थ नहीं है। एक पार्स वन एक एकल अस्पष्ट दस्तावेज (थोड़ा सा सरल) के लिए पार्स पेड़ों का एक सेट है जिसे विभिन्न तरीकों से पार्स किया जा सकता है। और यही सब जवाब के बारे में है। क्या आपकी धारा कचरे से अलग कई पूर्ण दस्तावेजों से बनी है, या क्या यह एक एकल दस्तावेज है जो आंशिक रूप से विकृत हो गया है। क्या आपके दस्तावेज़ को सिंटैक्टली रूप से सही माना जाता है या नहीं? उचित तकनीकी जवाब उसी पर निर्भर करता है।
बबलू

1
फिर पार्स वनों, और अर्ली, जीएलआर, मारपा, डेरिवेटिव के बारे में सभी उत्तर भूल जाएं। वे स्पष्ट रूप से नहीं हैं कि आप क्या चाहते हैं जब तक कि एक और कारण नहीं दिखता है। क्या आपके दस्तावेज़ वाक्यात्मक रूप से सही हैं? कुछ पार्सिंग तकनीक आंशिक रूप से विकृत दस्तावेजों के लिए संदर्भ को फिर से बना सकती है। क्या आपके पास इन दस्तावेजों के लिए एक सटीक वाक्यविन्यास है। क्या यह सभी के लिए समान है? क्या आप वास्तव में पार्स पेड़ों को चाहते हैं, या आप दस्तावेजों को अलग करके संतुष्ट होंगे, और संभवतः बाद में उन्हें अलग से पार्स करेंगे। मुझे लगता है कि मुझे पता है कि आपके प्रसंस्करण में क्या सुधार हो सकता है, लेकिन मुझे यकीन नहीं है कि आप इसे बंद कर सकते हैं।
19

जवाबों:


48

एक पार्सर जो पूरे इनपुट का उपभोग करने से पहले (आंशिक) परिणाम देता है उसे वृद्धिशील पार्सर कहा जाता है । वृद्धिशील पार्सिंग मुश्किल हो सकती है यदि एक व्याकरण में स्थानीय अस्पष्टताएं होती हैं जो केवल बाद में इनपुट में तय की जाती हैं। एक और कठिनाई पार्स पेड़ के उन हिस्सों को फैला रही है जो अभी तक नहीं पहुंचे हैं।

एक पार्सर जो सभी संभावित पार्स पेड़ों का एक जंगल लौटाता है - वह है, एक अस्पष्ट व्याकरण के प्रत्येक संभावित व्युत्पत्ति के लिए एक पार्स ट्री देता है - कहा जाता है ... मुझे यकीन नहीं है कि अगर इन चीजों का नाम अभी तक है। मुझे पता है कि मारपा पार्सर जनरेटर इसके लिए सक्षम है, लेकिन किसी भी अर्ली या जीएलआर आधारित पार्सर को इस से खींचने में सक्षम होना चाहिए।


हालाँकि, आप ऐसा नहीं चाहते हैं। आपके पास कई एम्बेडेड दस्तावेज़ों के साथ एक धारा है, जिसके बीच में कचरा है:

 garbagegarbage{key:42}garbagegarbage[1,2,3]{id:0}garbage...

आप एक ऐसा पार्सर चाहते हैं जो कचरे के ऊपर फिसल जाता है, और (lazily) प्रत्येक दस्तावेज़ के लिए एएसटीएस का एक क्रम देता है। यह हो सकता है इसकी सबसे सामान्य अर्थ में एक वृद्धिशील पार्सर माना जा। लेकिन आप वास्तव में इस तरह एक लूप लागू करेंगे:

while stream is not empty:
  try:
    yield parse_document(stream at current position)
  except:
    advance position in stream by 1 character or token

parse_docmentसमारोह तो एक पारंपरिक, गैर वृद्धिशील पार्सर होगा। यह सुनिश्चित करने की एक छोटी सी कठिनाई है कि आपने एक सफल पार्स के लिए पर्याप्त इनपुट स्ट्रीम पढ़ा है। इसे कैसे संभाला जा सकता है यह इस बात पर निर्भर करता है कि आप किस प्रकार के पार्सर का उपयोग कर रहे हैं। संभावनाओं में कुछ पार्स त्रुटियों पर एक बफर बढ़ाना, या आलसी टोकन का उपयोग करना शामिल है।

आलसी टोकन आपके इनपुट स्ट्रीम के कारण संभवतः सबसे सुरुचिपूर्ण समाधान है। लेसर चरण होने के बजाय टोकन की एक निश्चित सूची का उत्पादन, पार्सर आलसी कॉलबैक [1] से अगले टोकन का अनुरोध करेगा । लेक्सर तब जरूरत से ज्यादा धारा का उपभोग करता था। इस तरह, पार्सर केवल तभी विफल हो सकता है जब स्ट्रीम का वास्तविक अंत हो जाता है, या जब एक वास्तविक पार्स त्रुटि हुई (यानी हमने कचरे में रहते हुए भी पार्स करना शुरू कर दिया)।

[१] एक कॉलबैक-संचालित लीकर अन्य संदर्भों में भी एक अच्छा विचार है, क्योंकि यह सबसे लंबे समय तक टोकन मिलान के साथ कुछ समस्याओं से बच सकता है ।

यदि आप जानते हैं कि आप किस प्रकार के दस्तावेज़ खोज रहे हैं, तो आप केवल आशाजनक स्थानों पर रुकने के लिए स्किपिंग को अनुकूलित कर सकते हैं। उदाहरण के लिए एक JSON दस्तावेज़ हमेशा चरित्र {या के साथ शुरू होता है [। इसलिए, कचरा कोई भी स्ट्रिंग है जिसमें ये वर्ण नहीं होते हैं।


5
आपका स्यूडोकोड वास्तव में वही है जो मैं कर रहा हूं, लेकिन मुझे लगा कि यह सिर्फ एक बदसूरत हैक था। पार्सर दो प्रकार के अपवादों को फेंकता है ( NO_MATCHऔर UNDERFLOW) जो मुझे भेद करने की अनुमति देते हैं कि क्या मुझे स्ट्रीम स्थिति को आगे बढ़ाना चाहिए या अधिक इनपुट की प्रतीक्षा करनी चाहिए।
केविन क्रुमविडे

5
@ केविन: मैं कुछ सुरक्षा सुविधाओं के साथ, मालिकाना प्रारूप में एक नेटवर्क से आने वाले डेटा को संभालने के लिए भी इसका उपयोग करता हूं । इसके बारे में कुछ भी नहीं हैकी!
मोनिका

5

ऐसा करने वाले पार्सर के लिए एक विशिष्ट नाम नहीं है। लेकिन मैं एक एल्गोरिथ्म को उजागर करूंगा जो ऐसा करता है: डेरिवेटिव के साथ पार्स करना

यह एक समय में एक टोकन, इनपुट का उपभोग करता है। यह इनपुट के अंत में एक पार्स वन का उत्पादन करेगा। वैकल्पिक रूप से, आप पार्सिंग ( आंशिक पार्स) के बीच में पूरे पार्स वन को प्राप्त कर सकते हैं ।

डेरिवेटिव के साथ पार्सिंग संदर्भ-मुक्त व्याकरण को संभालता है, और अस्पष्ट व्याकरण के लिए पार्स वन का उत्पादन करेगा।

यह एक सुंदर सिद्धांत है, वास्तव में, लेकिन केवल इसकी प्रारंभिक अवस्था में है, और व्यापक रूप से तैनात नहीं किया गया है। मैट शायद स्काला / रैकेट / आदि में विभिन्न कार्यान्वयन के लिंक की एक सूची है।

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


4
डाउनवॉटर: क्या आप बता सकते हैं कि एक डाउनवोट के योग्य क्या था? अगर कुछ ऐसा है जिसे मुझे ठीक करने या सुधारने की आवश्यकता है, तो यकीन है कि यह जानना अच्छा होगा।
1639 में कॉर्नस्टैल्स

मैं नीच नहीं हूं, और मैं बिना टिप्पणी के नीच का सपना नहीं देखूंगा। लेकिन आपके उत्साहजनक पेपर में कई मौजूदा पार्सर्स का कोई संदर्भ नहीं है जो जटिलता और पार्स वन के बारे में एक ही परिणाम प्राप्त करते हैं। कार्यात्मक प्रोग्रामिंग महान है, लेकिन इस विषय पर मौजूदा साहित्य के साथ परिणाम की तुलना करना बहुत अच्छा है। आगे के उपयोग के लिए आपके पार्स वन कितने सुविधाजनक हैं?
Babou

@ बाबू: रिकॉर्ड के लिए, मैं उस ब्लॉग / पेपर का लेखक नहीं हूं। लेकिन हां, मैं मानता हूं कि मैं इस एल्गोरिथम की दूसरों के साथ तुलना करके इसे और विस्तार से जोड़ सकता हूं। मैट शायद इस पर एक पूरा व्याख्यान है , लेकिन इस उत्तर में इसे समेकित करना अच्छा होगा। अगर मुझे समय मिलता है तो मैं इस उत्तर का विस्तार करने की कोशिश करूंगा।
कॉर्नस्टॉक

1
इसका विस्तार करने में बहुत अधिक समय खर्च न करें। जहां तक ​​मैं बता सकता हूं, ओपी के बाद ऐसा नहीं है। उनके प्रश्न को ध्यानपूर्वक पढ़ने की आवश्यकता है। उसका तोते के जंगल का उपयोग तुम्हारा नहीं है। - - डेरिवेटिव के बारे में ... ऐसा लगता है कि यह दिलचस्प होना चाहिए, लेकिन किसी को इसे पिछले काम से संबंधित होना चाहिए ... और इसका एक महत्वपूर्ण निकाय है। लेकिन मुझे इस जवाब से मतलब नहीं है, लेकिन एम माइट, या उसके ब्लॉग के कागजात में।
बबौ

2

आदर्श से दूर, लेकिन मैंने इसे एक से अधिक बार देखा है: प्रत्येक इनपुट लाइन पर पार्स करने का प्रयास करें। यदि विफल रहता है, तो लाइन रखें और अगले को जोड़ें। छद्मकोश में:

buffer = ''
for each line from input:
    buffer = buffer + line
    if can parse buffer:
        emit tree
        buffer = ''

बड़ी समस्या यह है कि कुछ भाषाओं में आप यह नहीं जान सकते हैं कि अगली पंक्ति को पढ़ने से पहले कोई अभिव्यक्ति पूरी होती है या नहीं। उस स्थिति में, आपको लगता है कि आप अगले एक को पढ़ सकते हैं, और जांच सकते हैं कि क्या यह एक वैध शुरुआत है, या एक वैध निरंतरता है ... लेकिन इसके लिए आपको सटीक भाषा सिंटैक्स की आवश्यकता है

इससे भी बदतर, उन भाषाओं में एक पैथोलॉजिकल केस बनाना कठिन नहीं है, जिन्हें फ़ाइल के अंत तक पार्स नहीं किया जा सकता है, भले ही वह एक लंबा स्टेटमेंट न हो।


0

संक्षेप में

ऐसा लगता है कि आपकी समस्या का तेज़ समाधान एक REGEX, या एक FSA (परिमित राज्य ऑटोमेटन) को परिभाषित करना है, जो दस्तावेजों की सभी संभावित शुरुआत को पहचानता है (झूठी सकारात्मकता की अनुमति है, जो वास्तव में दस्तावेज़ के अनुरूप नहीं होगा)। फिर आप अपने इनपुट पर इसे बहुत तेज़ी से चला सकते हैं ताकि अगली जगह की पहचान हो सके जहाँ कुछ त्रुटियों के साथ एक दस्तावेज़ शुरू हो सके। यह एक दस्तावेज़ शुरू करने के लिए कुछ गलत स्थिति पैदा कर सकता है, लेकिन उन्हें पार्सर द्वारा मान्यता दी जाएगी और छोड़ दिया जाएगा।

तो Finite State Automaton वह पार्सर नाम हो सकता है जिसे आप खोज रहे थे। :)

समस्या

व्यावहारिक समस्या को समझना हमेशा कठिन होता है, खासकर जब शब्दावली की कई व्याख्या हो सकती है। पार्स वन शब्द को कॉन्टेक्स्ट-फ्री (CF) अस्पष्ट शब्दों के लिए गढ़ा गया (afaik), जिसमें कई पार्स-ट्री हैं। यह कुछ हद तक वाक्यों के एक जाली या अन्य प्रकार के व्याकरण के लिए सामान्यीकृत किया जा सकता है। इसलिए अर्ली, जीएलआर, मारपा और व्युत्पन्न पार्सर (कई अन्य हैं) के बारे में सभी जवाब जो इस मामले में प्रासंगिक नहीं थे।

लेकिन यह स्पष्ट रूप से नहीं है कि आपके मन में क्या है। आप एक अद्वितीय स्ट्रिंग को पार्स करना चाहते हैं जो कि अस्पष्ट दस्तावेजों का एक क्रम है, और प्रत्येक के लिए एक पार्स-ट्री या किसी प्रकार का संरचित प्रतिनिधित्व प्राप्त करें, क्योंकि आप वास्तव में यह नहीं कहते हैं कि आपके दस्तावेजों का वाक्यविन्यास कैसे परिभाषित किया जाता है, यह कहां से आता है देखने का एक औपचारिक भाषा बिंदु। आपके पास एक एल्गोरिथ्म और टेबल है जो किसी दस्तावेज़ की शुरुआत में पार्सिंग का काम करेगा। ऐसा ही होगा।

वास्तविक समस्या यह है कि आपके दस्तावेज़ की धारा में काफी कचरा है जो दस्तावेजों को अलग करता है। और ऐसा लगता है कि आपकी कठिनाई इस कचरे को जल्दी से स्कैन करने के लिए है। आपकी वर्तमान तकनीक शुरुआत में शुरू करने की है, और पहले चरित्र से स्कैन करने की कोशिश करें, और जब तक कि यह विफल न हो जाए, तब तक अगले वर्ण पर पुनरारंभ करें, जब तक कि आप एक संपूर्ण दस्तावेज़ स्कैन नहीं कर लेते। फिर आप दस्तावेज़ को स्कैन करने के बाद पहले चरित्र से बताते हुए दोहराते हैं।

वह भी अपने उत्तर के दूसरे भाग में @amon द्वारा सुझाया गया समाधान है ।

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

तो आपको वास्तव में क्या चाहिए एक एल्गोरिथ्म जो जल्दी से एक दस्तावेज़ की शुरुआत पा सकता है जो कचरे के बड़े पैमाने पर शुरू होता है। और आप भाग्यशाली हैं: इस तरह के एल्गोरिदम मौजूद हैं। और मुझे यकीन है कि आप इसे जानते हैं: इसे REGEX की खोज कहा जाता है।

सरल उपाय

आपको यह करने के लिए अपने दस्तावेज़ों के विनिर्देश का विश्लेषण करना है कि ये दस्तावेज़ कैसे शुरू होते हैं। मैं आपको बिल्कुल नहीं बता सकता कि कैसे, क्योंकि मुझे यकीन नहीं है कि उनके सिंटैक्स विनिर्देश को औपचारिक रूप से कैसे व्यवस्थित किया जाता है। संभवतः वे सभी एक परिमित सूची के कुछ शब्द से शुरू करते हैं, संभवतः कुछ विराम चिह्न या संख्याओं के साथ मिश्रित होते हैं। कि आप की जाँच करने के लिए है।

आपको जो करना है वह एक परिमित राज्य ऑटोमेटोन (FSA) को परिभाषित करना है, या अधिकांश प्रोग्रामर के लिए एक नियमित अभिव्यक्ति (REGEX) के समकक्ष है जो किसी दस्तावेज़ के पहले कुछ वर्णों को पहचान सकता है: अधिक, बेहतर, लेकिन इसकी बहुत आवश्यकता नहीं है बड़ा (जैसा कि समय और स्थान ले सकता है)। यह आपके दस्तावेज़ों के विनिर्देश से करना अपेक्षाकृत आसान होना चाहिए, और संभवतः एक प्रोग्राम के साथ स्वचालित रूप से किया जा सकता है जो आपके दस्तावेज़ों के विनिर्देश को पढ़ता है।

एक बार जब आप अपने regexp का उत्पादन कर लेते हैं, तो आप अपने इनपुट स्ट्रीम पर इसे अपने पहले (या अगले) दस्तावेज़ की शुरुआत में बहुत जल्दी प्राप्त करने के लिए चला सकते हैं:

मैं मानता हूं:
- docstartएक regex है जो सभी दस्तावेजों की शुरुआत से मेल खाता है
- search(regex, stream)एक ऐसा फ़ंक्शन है जो streamएक विकल्प के लिए खोज करता है जो मेल खाता है regex। जब यह वापस लौटता है, तो स्ट्रीम को इसके मिलान प्रत्यय से घटाकर पहले मिलान के विकल्प से शुरू किया जाता है, या खाली स्ट्रीम से कोई मेल नहीं मिलता है।
- parse(stream)धारा की शुरुआत से एक दस्तावेज़ को पार्स करने का प्रयास करता है (इसके बारे में क्या बचा है), और जो कुछ भी प्रारूप में पार्स ट्री को वापस करता है, या विफल रहता है। जब वह वापस लौटता है, तो धारा के दस्तावेज़ के अंत के तुरंत बाद स्थिति में शुरू होने वाले इसके प्रत्यय घटाव तक धारा कम हो जाती है। यदि पार्स विफल हो जाता है तो यह अपवाद कहता है।

forest = empty_forest
search(docstart, stream)
while stream is not empty:
  try:
    forest = forest + parse(stream)
  except
    remove first character from stream
  search(docstart, stream)

ध्यान दें कि पहले चरित्र को हटाना आवश्यक है ताकि अगली खोज फिर से उसी मैच को न मिले।

बेशक, धारा को छोटा करना एक छवि है। यह सिर्फ स्ट्रीम पर इंडेक्स हो सकता है।

एक अंतिम नोट यह है कि आपके रेगेक्स को बहुत सटीक होने की आवश्यकता नहीं है, जब तक कि यह सभी शुरुआत को पहचानता है। यदि यह कभी-कभी एक स्ट्रिंग को पहचानता है जो एक दस्तावेज़ की शुरुआत (झूठी सकारात्मक) नहीं हो सकती है, तो एकमात्र जुर्माना पार्सर के लिए एक बेकार कॉल की लागत है।

ताकि संभवतः उपयोगी होने पर रेगेक्स को सरल बनाने में मदद मिल सके।

तेजी से समाधान की संभावना के बारे में

उपरोक्त समाधान ज्यादातर मामलों में बहुत अच्छी तरह से काम करना चाहिए। हालाँकि, यदि आपके पास वास्तव में बहुत अधिक कचरा और फ़ाइल को संसाधित करने के लिए टेराबाइट्स हैं, तो अन्य एल्गोरिदम हो सकते हैं जो तेजी से चलते हैं।

यह विचार बॉयर-मूर स्ट्रिंग सर्च एल्गोरिदम से लिया गया है । यह एल्गोरिथ्म बहुत तेजी से एकल स्ट्रिंग के लिए एक धारा खोज सकता है क्योंकि यह स्ट्रिंग के एक संरचनात्मक विश्लेषण का उपयोग करता है, जिससे अधिकांश स्ट्रीम को पढ़ना छोड़ दिया जाता है, उन्हें देखने के बिना भी टुकड़ों पर कूद जाता है। यह एक स्ट्रिंग के लिए सबसे तेज़ खोज एल्गोरिथ्म है।

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

मैं आपको वेब पर मिले एक या दो बिंदुओं के साथ छोड़ रहा हूं, जिनमें से एक जाहिरा तौर पर एक रेफरीड शोध पत्र है , लेकिन आपको इसे अधिक सट्टा, संभवतः शोधपूर्ण माना जाना चाहिए, केवल तभी विचार किया जाना चाहिए जब आपके पास मजबूत प्रदर्शन समस्याएं थीं। और शायद शेल्फ प्रोग्राम में से कोई भी नहीं है जो इसे करेगा।


-2

आप जो वर्णन कर रहे हैं उसे SAX बनाम SOM के रूप में वर्णित किया जा सकता है।

SAX - (सिम्पल एपीआई फॉर एक्सएमएल) एक्सएमएल-डीईवी मेलिंग लिस्ट द्वारा एक्सएमएल डॉक्यूमेंट्स के लिए डेवलप किया गया एक ईवेंट सीक्वेंशियल एक्सेस पार्सर एपीआई है।

SOM - (XML स्कीमा ऑब्जेक्ट मॉडल) एक XML फ़ाइल की स्मृति प्रतिनिधित्व में यादृच्छिक अभिगम

सी #, और जावा में दोनों प्रकार के कार्यान्वयन हैं, और शायद बहुत अधिक हैं। आमतौर पर XSD या DTD वैकल्पिक है।

एसएएक्स की खुशी यह है कि यह कम मेमोरी ओवरहेड है, जो बड़ी एक्सएमएल फ़ाइलों के लिए महान है। व्यापार बंद यह है कि SAX का उपयोग करने वाला यादृच्छिक उपयोग या तो गैर-मौजूद है या धीमा है, और विकास का समय आमतौर पर SOM की तुलना में काफी अधिक है। एसओएम के साथ स्पष्ट समस्या संभावित रूप से बड़ी रैम आवश्यकताएं हैं।

यह उत्तर सभी प्लेटफार्मों और सभी भाषाओं के लिए लागू नहीं है।


1
आपको क्यों लगता है कि ओपी XML को पार्स कर रहा है?
दान पिचेलमैन

1
इस सवाल का जवाब नहीं है।

@Snowman लगभग अभी तक कुछ भी सवाल का जवाब नहीं दे रहा था, जिसमें स्वीकृत उत्तर का पहला भाग भी शामिल था। किसी को लेने का कोई मतलब नहीं। प्रश्न को सावधानीपूर्वक पढ़ने की आवश्यकता है।
बबौ

@ बबौ मैं किसी पर नहीं उठा रहा था, मैं अपने पतन की व्याख्या कर रहा था।

@ मेरे जाने- अनजाने समझाने वाले शोमैन । यह उचित है, और मुझे लगता है कि अधिक उपयोगकर्ता ऐसा करेंगे। मैं कोई मूल वक्ता नहीं हूँ: उस पर मेय्स चुनना बहुत ही मजबूत अभिव्यक्ति है। यह सिर्फ इतना है कि हर कोई अनुचित धारणा बना रहा है। तो यह भी ध्यान देने योग्य नहीं है। यह सच है कि यह एक दूसरों की तुलना में थोड़ा अधिक लगता है।
बबौ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.