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 ਸਕੀਮਾ ਜੋ ਮੈਂ ਕਦੇ ਦੇਖਿਆ ਹੈ, ਇਹ ਪੌਲੀਕਾਮ ਆਈਪੀ ਟੈਲੀਫੋਨੀ ਫੋਨਾਂ ਲਈ ਆਟੋਮੈਟਿਕ ਰਿਸੋਰਸ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਫਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ 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