क्या यह एक्सएमएल दस्तावेज़ों में लाइनब्रेक्स के प्रति संवेदनशील होने के लिए "खराब अभ्यास" है?

If you need your linebreaks preserved, use a CDATA block, as tweakt said

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

हां, मुझे लगता है कि एक सीडीएटीए ब्लॉक का उपयोग करना व्हाइटस्पेस की रक्षा करेगा। हालांकि कुछ पार्सर एपीआई आपको व्हाइटस्पेस को संरक्षित करने की अनुमति देते हैं।

आपको वास्तव में क्या करना चाहिए अपने एक्सएमएल को उस प्रारूप में परिवर्तित करना जो सफेद-स्थान को संरक्षित करता है।

So rather than seek to replace \n with
you should wrap the whole block in a

That way, your address is functionally preserved (whether you include line breaks or not) and the XSTL can choose whether to preserve white-space in the result.

I don't see what's wrong with tags.
Apparently, the visualization of the data is important to you, important enough to keep it in your data (via line breaks in your first example). Fine. Then really keep it, don't rely on "magic" to keep it for you. Keep every bit of data you'll need later on and can't deduce perfectly from the saved portion of the data, keep it even if it's visualization data (line breaks and other formatting). Your user (end user of another developer) took the time to format that data to his liking - either tell him (API doc / text near the input) that you don't intend on keeping it, or - just keep it.

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

मैं कहूंगा कि आम तौर पर यह एक बड़ी समस्या नहीं है, लेकिन इस मामले में मुझे लगता है कि रेखा टैग सबसे सही है क्योंकि यह स्पष्ट रूप से दिखाता है कि आप वास्तव में यह नहीं समझते कि विभिन्न संस्कृतियों में रेखाओं का क्या अर्थ हो सकता है। (याद रखें कि पते में प्रवेश करने के लिए अधिकांश रूपों में ज़िप कोड आदि है, और पता पंक्ति 1 और 2.)

The awkwardness of having the line tag comes with normal XML, and has been much debated at coding horror. http://www.codinghorror.com/blog/archives/001139.html

मुझे लगता है कि एकमात्र वास्तविक समस्या यह है कि यह एक्सएमएल को पढ़ने में कठोर बनाता है। जैसे

    
        
            
15 Sample St
Example Bay
Some Country
        
    

If pretty xml isn't a concern, I'd probably not worry about it, so long as it's working. If pretty xml is a concern, I'd convert the explicit newlines into
tags or \n before embedding them in the XML.

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

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

एक और संभावित समस्या यह है कि यदि आप अपने एक्सएमएल दस्तावेज़ को एक्सएमएल एडिटर में खोलते हैं और इसे प्रिंट-प्रिंट करते हैं, तो आप उन लाइन ब्रेक को खोने की संभावना रखते हैं।

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

कुछ पढ़ने का सुझाव दिया

• एक XML.com से आलेख कहता है निम्नलिखित:

एक्सएमएल अनुप्रयोग अक्सर एक लगते हैं   सफेद जगह की ओर cavalier रवैया   क्योंकि स्थानों के बारे में नियम   एक एक्सएमएल दस्तावेज़ जहां व्हाइटस्पेस   कभी-कभी ये कोई फर्क नहीं पड़ता   जोड़ने के लिए आवेदन मुक्त रीइन या   कुछ स्थानों में सफेद जगह हटा दें।

• A collection of XSL-list posts regarding whitespace.

The xml spec has something to say regarding whitespace and linefeeds and carriage returns in particular. So if you limit yourself to true linefeeds (x0A) you should be Ok. However, many editing tools will reformat xml for "better presentation" and possibly get rid of the special syntax. A more robust and cleaner approach than the "< line>" idea would be to simply use namespaces and embed XHTML content, e.g.:

15 Sample St
Example Bay
Some Country

जब मानक शब्दावली की बात आती है तो पहिया को फिर से शुरू करने की आवश्यकता नहीं होती है।

यह इस बात पर निर्भर करता है कि आप xml को कैसे पढ़ रहे हैं और लिख रहे हैं।

If xml is being generated automatically - if newlines or explicit \n flags are being parsed into
- then there's nothing to worry about. Your input likely doesn't have any other xml in it so it's just cleaner to not mess with xml at all.

यदि टैग मैन्युअल रूप से काम किए जा रहे हैं, तो यदि आप मुझसे पूछें तो अभी भी लाइन ब्रेक होने के लिए अभी भी क्लीनर है।

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

अगर एक्सएमएल खराब दिखता है (विशेष रूप से जब स्वचालित रूप से जेनरेट किया जाता है), तो Tidy मदद कर सकता है, हालांकि यह HTML के साथ बेहतर काम करता है एक्सएमएल के मुकाबले।

I recommend you should either add the
line breaks or maybe use line-break entity -

टेक्स्ट नोड्स के बजाय डेटा स्टोर करने के लिए विशेषताओं का उपयोग करने के बारे में क्या:

मुझे पता है कि विशेषताओं का उपयोग बनाम टेक्स्ट नोड्स अक्सर बहस वाले विषय होते हैं, लेकिन मैं समय के 9 5% गुणों के साथ अटक गया हूं, और इसके कारण कोई परेशानी नहीं हुई है।

कुछ लोगों ने कहा है कि सीडीएटीए ब्लॉक आपको लाइन ब्रेक बनाए रखने की अनुमति देगा। ये गलत है। सीडीएटीए अनुभाग केवल मार्कअप को चरित्र डेटा के रूप में संसाधित कर देगा, वे लाइन ब्रेक प्रोसेसिंग को नहीं बदल देंगे।

15 Sample St
Example Bay
Some Country

बिल्कुल वही है

केवल अंतर यह है कि विभिन्न एपीआई इसकी रिपोर्ट कैसे करते हैं।