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 ಬಳಕೆಯು ಮೂಲಭೂತವಾಗಿ ಸ್ಕೀಯೊಮಾರ್ಫಿಸಂನ ಅಭಿವ್ಯಕ್ತಿಯಾಗಿದೆ. ಸೀಮಿತ ಗಾತ್ರದ ಮುದ್ರಿತ ಪುಟದ ರೂಪಕ ಕಲ್ಪನೆಯನ್ನು ಜನರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಮುದ್ರಿತ ದಾಖಲೆಗಳ ಆಧಾರದ ಮೇಲೆ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಎಂಬುದನ್ನು ಅವರು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಅದು ನಿಮ್ಮ ಮಾರ್ಗದರ್ಶಿಯಾಗಿದ್ದರೆ, ಯಂತ್ರ-ಓದಬಲ್ಲ ಭೌತಿಕ ಗಾತ್ರದ ಮಿತಿಗಳಿಲ್ಲದ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು-XML ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು-ಪರಿಚಿತ ಮತ್ತು ಆರಾಮದಾಯಕ ಡಾಕ್ಯುಮೆಂಟ್ ಪ್ರತಿರೂಪವಾಗಿರುವಾಗ ನಾವೀನ್ಯತೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. ದತ್ತಾಂಶವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವ ತಪ್ಪಾದ ಮತ್ತು ಅತಿಯಾದ ಸ್ಕೆಯುಮಾರ್ಫಿಕ್ ಮಾರ್ಗವಾಗಿ ಉಳಿಯುವುದನ್ನು ಇದು ತಡೆಯುವುದಿಲ್ಲ.

ಇಲ್ಲಿಯವರೆಗೆ, ನನಗೆ ತಿಳಿದಿರುವ ಏಕೈಕ XML ಸ್ಕೀಮಾಗಳು XHTML ಮತ್ತು DocBook ಸ್ವರೂಪದ ಮಾನ್ಯವಾದ ಬಳಕೆಯನ್ನು ನಾನು ನಿಜವಾಗಿಯೂ ಕರೆಯಬಹುದು.

ಮೂಲ: www.habr.com