XML ຖືກໃຊ້ໃນທາງຜິດເກືອບສະເໝີ

ພາສາ XML ຖືກສ້າງຂື້ນໃນປີ 1996. ມັນປະກົດວ່າບໍ່ໄວກວ່າຄວາມເປັນໄປໄດ້ຂອງຄໍາຮ້ອງສະຫມັກຂອງມັນໄດ້ເລີ່ມຕົ້ນແລ້ວທີ່ຈະເຂົ້າໃຈຜິດ, ແລະສໍາລັບຈຸດປະສົງທີ່ເຂົາເຈົ້າພະຍາຍາມປັບມັນ, ມັນບໍ່ແມ່ນທາງເລືອກທີ່ດີທີ່ສຸດ.

ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ຈະເວົ້າວ່າສ່ວນໃຫຍ່ຂອງ XML schemas ທີ່ຂ້ອຍໄດ້ເຫັນແມ່ນການໃຊ້ XML ທີ່ບໍ່ເຫມາະສົມຫຼືບໍ່ຖືກຕ້ອງ. ຍິ່ງໄປກວ່ານັ້ນ, ການໃຊ້ XML ນີ້ສະແດງໃຫ້ເຫັນຄວາມເຂົ້າໃຈຜິດພື້ນຖານຂອງສິ່ງທີ່ XML ແມ່ນກ່ຽວກັບ.

XML ເປັນພາສາ markup. ນີ້ບໍ່ແມ່ນຮູບແບບຂໍ້ມູນ. schemas XML ສ່ວນໃຫຍ່ໄດ້ມອງຂ້າມຄວາມແຕກຕ່າງນີ້ຢ່າງຈະແຈ້ງ, ເຮັດໃຫ້ XML ສັບສົນກັບຮູບແບບຂໍ້ມູນ, ເຊິ່ງໃນທີ່ສຸດກໍ່ເຮັດໃຫ້ເກີດຄວາມຜິດພາດໃນການເລືອກ XML ເພາະວ່າມັນເປັນຮູບແບບຂໍ້ມູນທີ່ຕ້ອງການຕົວຈິງ.

ໂດຍບໍ່ມີການເຂົ້າໄປໃນລາຍລະອຽດຫຼາຍເກີນໄປ, XML ແມ່ນເຫມາະສົມທີ່ສຸດສໍາລັບການອະທິບາຍຕັນຂອງຂໍ້ຄວາມທີ່ມີໂຄງສ້າງແລະ metadata. ຖ້າເປົ້າຫມາຍຕົ້ນຕໍຂອງທ່ານບໍ່ແມ່ນການເຮັດວຽກກັບບລັອກຂອງຂໍ້ຄວາມ, ການເລືອກ XML ຄົງຈະບໍ່ເປັນເຫດຜົນ.

ຈາກຈຸດນີ້, ມີວິທີງ່າຍໆທີ່ຈະກວດເບິ່ງວ່າ XML schema ຖືກສ້າງຂື້ນແນວໃດ. ໃຫ້ເອົາເປັນຕົວຢ່າງເອກະສານໃນ schema ທີ່ຕັ້ງໄວ້ແລະເອົາ tags ແລະຄຸນລັກສະນະທັງຫມົດອອກຈາກມັນ. ຖ້າສິ່ງທີ່ປະໄວ້ບໍ່ມີຄວາມຫມາຍ (ຫຼືຖ້າມີເສັ້ນຫວ່າງເປົ່າ), ຫຼັງຈາກນັ້ນ schema ຂອງທ່ານບໍ່ໄດ້ຖືກສ້າງຢ່າງຖືກຕ້ອງຫຼືທ່ານບໍ່ຄວນໃຊ້ XML.

ຂ້າງລຸ່ມນີ້ຂ້າພະເຈົ້າຈະໃຫ້ບາງຕົວຢ່າງທົ່ວໄປທີ່ສຸດຂອງວົງຈອນການກໍ່ສ້າງທີ່ບໍ່ຖືກຕ້ອງ.

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

ໃນທີ່ນີ້ພວກເຮົາເຫັນຕົວຢ່າງຂອງຄວາມພະຍາຍາມທີ່ບໍ່ມີພື້ນຖານແລະແປກ (ເຖິງແມ່ນວ່າທົ່ວໄປຫຼາຍ) ທີ່ຈະສະແດງວັດຈະນານຸກົມ key-value ງ່າຍໆໃນ XML. ຖ້າທ່ານເອົາ tags ແລະຄຸນລັກສະນະທັງຫມົດອອກ, ທ່ານຈະຖືກປະໄວ້ກັບແຖວຫວ່າງເປົ່າ. ໂດຍພື້ນຖານແລ້ວ, ເອກະສານນີ້ແມ່ນ, ບໍ່ວ່າມັນຈະເປັນເລື່ອງໂງ່, ເປັນຄໍາບັນຍາຍ semantic ຂອງເສັ້ນຫວ່າງເປົ່າ.

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

ເພື່ອເຮັດໃຫ້ບັນຫາຮ້າຍແຮງກວ່າເກົ່າ, ພວກເຮົາບໍ່ພຽງແຕ່ມີຄໍາບັນຍາຍ semantic ຂອງ string ຫວ່າງເປົ່າຢູ່ທີ່ນີ້ເປັນວິທີການ extravagant ຂອງການສະແດງວັດຈະນານຸກົມ - ເວລານີ້ "ພົດຈະນານຸກົມ" ຖືກເຂົ້າລະຫັດໂດຍກົງເປັນຄຸນລັກສະນະຂອງອົງປະກອບຮາກ. ນີ້ເຮັດໃຫ້ຊຸດຂອງຄຸນລັກສະນະຂອງຊື່ອົງປະກອບທີ່ບໍ່ຖືກກໍານົດແລະເຄື່ອນໄຫວ. ຍິ່ງໄປກວ່ານັ້ນ, ມັນສະແດງໃຫ້ເຫັນວ່າຜູ້ຂຽນທັງຫມົດຕ້ອງການສະແດງອອກແມ່ນ syntax ທີ່ສໍາຄັນທີ່ງ່າຍດາຍ, ແຕ່ແທນທີ່ລາວໄດ້ຕັດສິນໃຈທີ່ແປກປະຫຼາດທີ່ຈະນໍາໃຊ້ XML, ບັງຄັບໃຊ້ອົງປະກອບທີ່ຫວ່າງເປົ່າພຽງແຕ່ເປັນຄໍານໍາຫນ້າເພື່ອນໍາໃຊ້ syntax ຄຸນລັກສະນະ. ແລະຂ້ອຍໄດ້ພົບກັບໂຄງການດັ່ງກ່າວເລື້ອຍໆ.

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

ນີ້ແມ່ນບາງສິ່ງບາງຢ່າງທີ່ດີກວ່າ, ແຕ່ໃນປັດຈຸບັນສໍາລັບບາງເຫດຜົນທີ່ສໍາຄັນແມ່ນ metadata ແລະຄ່າບໍ່ແມ່ນ. ເບິ່ງວັດຈະນານຸກົມທີ່ແປກປະຫຼາດຫຼາຍ. ຖ້າທ່ານເອົາ tags ແລະຄຸນລັກສະນະທັງຫມົດ, ຂໍ້ມູນເຄິ່ງຫນຶ່ງຈະສູນເສຍ.

ການສະແດງວັດຈະນານຸກົມທີ່ຖືກຕ້ອງໃນ 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 ແມ່ນບໍ່ເຫມາະສົມສໍາລັບເລື່ອງນີ້.

Schema XML ທີ່ຮ້າຍແຮງທີ່ສຸດ? ໂດຍວິທີທາງການ, ລາງວັນສໍາລັບ schema XML ທີ່ຮ້າຍແຮງທີ່ສຸດທີ່ຂ້ອຍເຄີຍເຫັນ, ໄດ້ຮັບຮູບແບບໄຟລ໌ການຕັ້ງຄ່າອັດຕະໂນມັດສໍາລັບໂທລະສັບ Polycom IP. ໄຟລ໌ດັ່ງກ່າວຮຽກຮ້ອງໃຫ້ມີການດາວໂຫຼດໄຟລ໌ຄໍາຮ້ອງຂໍ XML ຜ່ານ TFTP, ເຊິ່ງ... ໂດຍທົ່ວໄປແລ້ວ, ນີ້ແມ່ນການຄັດຫຍໍ້ມາຈາກໄຟລ໌ດັ່ງກ່າວ:

<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/> ແລະອື່ນໆ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າມັນເບິ່ງຄືວ່າບໍ່ຈໍາເປັນຢ່າງສົມບູນແລະຢູ່ glance ທໍາອິດບໍ່ມີຄວາມຫມາຍ.
• ແລະສຸດທ້າຍ, ຖ້າທ່ານຫວັງວ່າອົງປະກອບທໍາອິດຂອງຊື່ຄຸນລັກສະນະຈະຄືກັນກັບຊື່ອົງປະກອບ - ບໍ່ມີຫຍັງຄືກັນ! ຕົວຢ່າງ, ຄຸນລັກສະນະ up. ຕ້ອງຕິດຢູ່ກັບ <userpreferences/>. ຄໍາສັ່ງຂອງການຕິດຊື່ຄຸນລັກສະນະກັບອົງປະກອບແມ່ນ arbitrary, ເກືອບຫມົດ.

ເອກະສານ ຫຼືຂໍ້ມູນ. ທຸກໆຄັ້ງ, ບາງຄົນເຮັດບາງສິ່ງບາງຢ່າງທີ່ແປກປະຫຼາດໂດຍພະຍາຍາມປຽບທຽບ XML ແລະ JSON - ແລະດັ່ງນັ້ນຈຶ່ງສະແດງໃຫ້ເຫັນວ່າພວກເຂົາບໍ່ເຂົ້າໃຈຄືກັນ. XML ເປັນພາສາ markup ເອກະສານ. JSON ແມ່ນຮູບແບບຂໍ້ມູນທີ່ມີໂຄງສ້າງ, ດັ່ງນັ້ນການປຽບທຽບພວກມັນກັບກັນແລະກັນແມ່ນຄ້າຍຄືການພະຍາຍາມປຽບທຽບຄວາມອົບອຸ່ນກັບຄວາມອ່ອນໂຍນ.

ແນວຄວາມຄິດຂອງຄວາມແຕກຕ່າງລະຫວ່າງ ເອ​ກະ​ສານ​ແລະ​ຂໍ້​ມູນ​. ໃນຖານະເປັນການປຽບທຽບຂອງ XML, ພວກເຮົາສາມາດເອົາເອກະສານທີ່ສາມາດອ່ານໄດ້ຕາມເງື່ອນໄຂ. ເຖິງແມ່ນວ່າມັນມີຈຸດປະສົງເພື່ອໃຫ້ເຄື່ອງສາມາດອ່ານໄດ້, ມັນຫມາຍເຖິງການປຽບທຽບກັບເອກະສານ, ແລະຈາກຈຸດນີ້ຕົວຈິງແລ້ວແມ່ນປຽບທຽບກັບເອກະສານ PDF, ເຊິ່ງສ່ວນຫຼາຍແມ່ນບໍ່ສາມາດອ່ານໄດ້ດ້ວຍເຄື່ອງ.

ສໍາລັບຕົວຢ່າງ, ໃນ XML ຄໍາສັ່ງຂອງອົງປະກອບທີ່ສໍາຄັນ. ແຕ່ໃນ JSON, ຄໍາສັ່ງຂອງຄູ່ຄີ-ຄ່າພາຍໃນວັດຖຸແມ່ນບໍ່ມີຄວາມຫມາຍແລະບໍ່ໄດ້ກໍານົດ. ຖ້າທ່ານຕ້ອງການທີ່ຈະເອົາວັດຈະນານຸກົມທີ່ບໍ່ມີຄໍາສັ່ງຂອງຄູ່ຄີ-ຄ່າ, ຄໍາສັ່ງທີ່ແທ້ຈິງທີ່ອົງປະກອບປາກົດຢູ່ໃນໄຟລ໌ນັ້ນບໍ່ສໍາຄັນ. ແຕ່ທ່ານສາມາດປະກອບຂໍ້ມູນຫຼາຍປະເພດທີ່ແຕກຕ່າງກັນຈາກຂໍ້ມູນນີ້. ຂອງເອກະສານ, ເນື່ອງຈາກວ່າມີຄໍາສັ່ງທີ່ແນ່ນອນໃນເອກະສານ. ໃນທາງປຽບທຽບ, ມັນຄ້າຍຄືກັນກັບເອກະສານໃນເຈ້ຍ, ເຖິງແມ່ນວ່າມັນບໍ່ມີຂະຫນາດທາງດ້ານຮ່າງກາຍ, ບໍ່ເຫມືອນກັບເອກະສານພິມຫຼືເອກະສານ PDF.

ຕົວຢ່າງຂອງຂ້ອຍກ່ຽວກັບການເປັນຕົວແທນຂອງວັດຈະນານຸກົມ XML ທີ່ເຫມາະສົມສະແດງໃຫ້ເຫັນຄໍາສັ່ງຂອງອົງປະກອບໃນວັດຈະນານຸກົມ, ກົງກັນຂ້າມກັບການເປັນຕົວແທນຂອງ JSON. ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ສາ​ມາດ​ລະ​ເລີຍ​ຄໍາ​ສັ່ງ​ນີ້​: linearity ນີ້​ແມ່ນ​ມີ​ຢູ່​ໃນ​ຮູບ​ແບບ​ເອ​ກະ​ສານ​ແລະ​ຮູບ​ແບບ XML​. ບາງຄົນອາດຈະເລືອກທີ່ຈະບໍ່ສົນໃຈຄໍາສັ່ງໃນເວລາທີ່ຕີຄວາມຫມາຍເອກະສານ XML ນີ້, ແຕ່ບໍ່ມີຈຸດໃດທີ່ຈະໂຕ້ຖຽງກ່ຽວກັບເລື່ອງນີ້ເນື່ອງຈາກບັນຫາແມ່ນເກີນຂອບເຂດຂອງການສົນທະນາຂອງຮູບແບບຂອງມັນເອງ. ຍິ່ງໄປກວ່ານັ້ນ, ຖ້າທ່ານເຮັດໃຫ້ເອກະສານສາມາດເບິ່ງໄດ້ໃນຕົວທ່ອງເວັບໂດຍການຕິດແຜ່ນແບບ cascading ກັບມັນ, ທ່ານຈະເຫັນວ່າອົງປະກອບວັດຈະນານຸກົມປາກົດຢູ່ໃນລໍາດັບທີ່ແນ່ນອນແລະບໍ່ມີບ່ອນອື່ນ.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ວັດຈະນານຸກົມ (ຊິ້ນສ່ວນຂອງຂໍ້ມູນທີ່ມີໂຄງສ້າງ) ສາມາດຖືກປ່ຽນເປັນ n ເອກະສານທີ່ເປັນໄປໄດ້ຕ່າງໆ (ໃນ XML, PDF, ເຈ້ຍ, ແລະອື່ນໆ), ບ່ອນທີ່ n - ຈໍານວນຂອງການປະສົມປະສານທີ່ເປັນໄປໄດ້ຂອງອົງປະກອບໃນວັດຈະນານຸກົມ, ແລະພວກເຮົາຍັງບໍ່ທັນໄດ້ຄໍານຶງເຖິງຕົວແປທີ່ເປັນໄປໄດ້ອື່ນໆ.

ຢ່າງໃດກໍ່ຕາມ, ມັນຍັງປະຕິບັດຕາມວ່າຖ້າທ່ານຕ້ອງການໂອນຂໍ້ມູນພຽງແຕ່, ຫຼັງຈາກນັ້ນການນໍາໃຊ້ເອກະສານທີ່ສາມາດອ່ານໄດ້ດ້ວຍເຄື່ອງຈັກສໍາລັບການນີ້ຈະບໍ່ມີປະສິດທິພາບ. ມັນໃຊ້ຕົວແບບ, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນ superfluous; ມັນຈະເຂົ້າໄປໃນທາງເທົ່ານັ້ນ. ນອກຈາກນັ້ນ, ເພື່ອສະກັດຂໍ້ມູນແຫຼ່ງ, ທ່ານຈະຕ້ອງຂຽນໂປຼແກຼມ. ບໍ່ຄ່ອຍມີຈຸດໃດໃນການນໍາໃຊ້ XML ສໍາລັບບາງສິ່ງບາງຢ່າງທີ່ຈະບໍ່ຖືກຈັດຮູບແບບເປັນເອກະສານໃນບາງຈຸດ (ເວົ້າວ່າ, ການນໍາໃຊ້ CSS ຫຼື XSLT, ຫຼືທັງສອງ), ເນື່ອງຈາກວ່ານັ້ນແມ່ນເຫດຜົນຕົ້ນຕໍ (ຖ້າບໍ່ແມ່ນພຽງແຕ່) ສໍາລັບການປະຕິບັດຕາມ. ກັບຮູບແບບເອກະສານ.

ຍິ່ງໄປກວ່ານັ້ນ, ເນື່ອງຈາກ XML ບໍ່ມີແນວຄວາມຄິດຂອງຕົວເລກ (ຫຼືການສະແດງອອກ Boolean, ຫຼືປະເພດຂໍ້ມູນອື່ນໆ), ຕົວເລກທັງຫມົດທີ່ເປັນຕົວແທນໃນຮູບແບບນີ້ແມ່ນພິຈາລະນາພຽງແຕ່ຂໍ້ຄວາມເພີ່ມເຕີມ. ເພື່ອສະກັດຂໍ້ມູນ, schema ແລະຄວາມສໍາພັນຂອງມັນກັບຂໍ້ມູນທີ່ກົງກັນທີ່ຖືກສະແດງອອກຕ້ອງເປັນທີ່ຮູ້ຈັກ. ນອກນັ້ນທ່ານຍັງຈໍາເປັນຕ້ອງຮູ້ວ່າເວລາໃດ, ອີງຕາມສະພາບການ, ອົງປະກອບຂໍ້ຄວາມສະເພາະເປັນຕົວແທນຕົວເລກແລະຄວນຈະຖືກປ່ຽນເປັນຕົວເລກ, ແລະອື່ນໆ.

ດັ່ງນັ້ນ, ຂະບວນການສະກັດຂໍ້ມູນຈາກເອກະສານ XML ແມ່ນບໍ່ແຕກຕ່າງກັນຫຼາຍຈາກຂະບວນການຮັບຮູ້ເອກະສານສະແກນທີ່ປະກອບດ້ວຍ, ສໍາລັບການຍົກຕົວຢ່າງ, ຕາຕະລາງປະກອບເປັນຈໍານວນຫຼາຍຫນ້າຂອງຂໍ້ມູນຕົວເລກ. ແມ່ນແລ້ວ, ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດສິ່ງນີ້ໃນຫຼັກການ, ແຕ່ນີ້ບໍ່ແມ່ນວິທີທີ່ດີທີ່ສຸດ, ຍົກເວັ້ນວິທີສຸດທ້າຍ, ເມື່ອບໍ່ມີທາງເລືອກອື່ນຢ່າງແທ້ຈິງ. ການແກ້ໄຂທີ່ສົມເຫດສົມຜົນແມ່ນພຽງແຕ່ຊອກຫາສໍາເນົາດິຈິຕອຂອງຂໍ້ມູນຕົ້ນສະບັບທີ່ບໍ່ໄດ້ຝັງຢູ່ໃນຮູບແບບເອກະສານທີ່ປະສົມປະສານຂໍ້ມູນກັບຕົວຫນັງສືສະເພາະຂອງມັນ.

ທີ່ເວົ້າວ່າ, ມັນບໍ່ແປກໃຈຂ້ອຍເລີຍວ່າ XML ເປັນທີ່ນິຍົມໃນທຸລະກິດ. ເຫດຜົນສໍາລັບການນີ້ແມ່ນຊັດເຈນວ່າຮູບແບບເອກະສານ (ໃນເຈ້ຍ) ແມ່ນເຂົ້າໃຈແລະຄຸ້ນເຄີຍກັບທຸລະກິດ, ແລະພວກເຂົາຕ້ອງການທີ່ຈະສືບຕໍ່ນໍາໃຊ້ຮູບແບບທີ່ຄຸ້ນເຄີຍແລະເຂົ້າໃຈໄດ້. ສໍາລັບເຫດຜົນດຽວກັນ, ທຸລະກິດເກີນໄປມັກຈະໃຊ້ເອກະສານ PDF ແທນທີ່ຈະເປັນຮູບແບບທີ່ສາມາດອ່ານໄດ້ໂດຍເຄື່ອງຈັກ - ເພາະວ່າພວກມັນຍັງຕິດກັບແນວຄວາມຄິດຂອງຫນ້າພິມທີ່ມີຂະຫນາດທາງດ້ານຮ່າງກາຍສະເພາະ. ອັນນີ້ຍັງໃຊ້ໄດ້ກັບເອກະສານທີ່ບໍ່ໜ້າຈະພິມໄດ້ (ຕົວຢ່າງເຊັ່ນເອກະສານການລົງທະບຽນ 8000 ໜ້າ PDF). ຈາກຈຸດນີ້, ການນໍາໃຊ້ XML ໃນທຸລະກິດແມ່ນສໍາຄັນຕໍ່ການສະແດງອອກຂອງ skeuomorphism. ປະຊາຊົນເຂົ້າໃຈແນວຄວາມຄິດ metaphorical ຂອງຫນ້າພິມທີ່ມີຂະຫນາດຈໍາກັດ, ແລະພວກເຂົາເຂົ້າໃຈວິທີການສ້າງຂະບວນການທຸລະກິດໂດຍອີງໃສ່ເອກະສານພິມ. ຖ້ານັ້ນແມ່ນຄໍາແນະນໍາຂອງເຈົ້າ, ເອກະສານທີ່ບໍ່ມີຂໍ້ຈໍາກັດຂະຫນາດທາງດ້ານຮ່າງກາຍທີ່ສາມາດອ່ານໄດ້ໂດຍເຄື່ອງຈັກ - ເອກະສານ XML - ສະແດງເຖິງການປະດິດສ້າງໃນຂະນະທີ່ເປັນເອກະສານທີ່ຄຸ້ນເຄີຍແລະສະດວກສະບາຍ. ອັນນີ້ບໍ່ໄດ້ປ້ອງກັນເຂົາເຈົ້າຈາກການເປັນວິທີການນໍາສະເຫນີຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງ ແລະ skeuomorphic ຫຼາຍເກີນໄປ.

ມາຮອດປະຈຸ, schemas XML ເທົ່ານັ້ນທີ່ຂ້ອຍຮູ້ວ່າຂ້ອຍສາມາດເອີ້ນໃຊ້ຮູບແບບທີ່ຖືກຕ້ອງຢ່າງແທ້ຈິງແມ່ນ XHTML ແລະ DocBook.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com