บทช่วยสอน XML อย่างง่ายสาม

อนาคตของ XML ตอนนี้คุณรู้แล้วว่า XML เป็นความจริงที่ว่าโครงสร้างนั้นซับซ้อนเล็กน้อย และ DTD มีตัวเลือกมากมายในการกำหนดสิ่งที่เอกสารสามารถบรรจุได้ แต่นั่นไม่ใช่ทั้งหมด

พิจารณาอุตสาหกรรมที่การแลกเปลี่ยนข้อมูลมีความสำคัญ เช่น การธนาคาร ธนาคารใช้ระบบความเป็นเจ้าของเพื่อติดตามธุรกรรมภายใน แต่หากพวกเขาใช้รูปแบบ XML ทั่วไปบนเว็บ พวกเขาจะต้องอธิบายข้อมูลธุรกรรมให้กับสถาบันหรือแอปพลิเคชันอื่น (เช่น Quicken หรือ MS Money) แน่นอนว่ายังสามารถแสดงข้อมูลบนเว็บเพจได้อีกด้วย โปรดทราบ: ไม่มีแท็กนี้ เรียกว่า OFEX การแลกเปลี่ยนทางการเงินแบบเปิด

ภายใต้สถานการณ์บางอย่าง หาก IE 4 บนพีซีพบแท็ก <SOFTPKG> ฟังก์ชันจะเริ่มต้นขึ้นเพื่อให้ผู้ใช้สามารถอัปเดตซอฟต์แวร์ที่ติดตั้งได้ หากคุณใช้ Windows 98 คุณอาจเคยเห็นสถานการณ์นี้ แต่ไม่รู้ว่าเป็นแอปพลิเคชัน XML

เรามีแอปพลิเคชัน XML สามแอปพลิเคชันที่ดูแตกต่างจากการเพิ่มเครื่องจักร เครื่องพิมพ์ดีด และดินสอที่ Andy Grove เห็นในปี 1970 แต่คล้ายกับแอปพลิเคชันที่ปรากฏบนพีซีในที่สุด ประโยชน์ของ XML สามารถอธิบายได้โดยทั่วไปว่า: "เมื่อคุณใช้แท็กที่มนุษย์และเครื่องสามารถอ่านได้เพื่ออธิบายข้อมูลของคุณ สิ่งที่ดีจะเกิดขึ้น"

สิ่งดีๆ เหล่านั้นจะเกิดขึ้น ? ฉันไม่มีความคิด แต่ฉันก็ไม่รู้เหมือนกันว่าโปรแกรมรุ่นต่อไปบนพีซีของฉันจะเป็นอย่างไร ตราบใดที่ข้อมูลถูกแท็กด้วยวิธีนี้ ก็สามารถสร้างแอปพลิเคชันต่างๆ ได้

คุณเริ่มคิดว่ามันจะขยายไปได้ไกลแค่ไหน?

เรามีแอปพลิเคชัน XML ที่ใช้งานได้จริงมากมายให้พูดคุยกัน และฉันจะกล่าวถึงสิ่งเหล่านี้ในอนาคตอันใกล้นี้ เนื่องจากเราทุกคนล้วนเป็นผู้ใช้อินเทอร์เน็ต อนาคตจะเป็น XSL (Extensible Style Language-
ภาษาสไตล์ eXtensible)

อีกอย่างสูตรนี้เป็นของแม่เราจริงๆและก็อร่อยมากด้วย ถ้าจะใช้ก็เติมมะพร้าวขูดอีกครึ่งถ้วย

ฉันเขียนสิ่งนี้เพราะฉันใส่ใจจริงๆ เกี่ยวกับสิ่งที่คุณคิดกับฉัน ข้อกังวลของฉันคือ หากคุณอ่านบทนำของฉันเกี่ยวกับ XML และพร้อมที่จะเริ่มเขียนเอกสาร XML ของคุณเอง ดังนั้นคุณจึงเริ่มมองหา DTD ที่จัดตั้งขึ้นแล้วเพื่อแสดงข้อมูลของคุณ คุณพบสิ่งหนึ่งดังที่แสดงด้านล่าง:

<!ATTLIST fn

%attr.lang;

value CDATA #FIXED "TEXT">

<!ENTITY % attr.img "

img.type CDATA #REQUIRED

img.data ENTITY #REQUIRED">

ทันทีที่คุณคิดว่าเจย์ต้องเป็นคนงี่เง่า เขาไม่ได้พูดอะไรเกี่ยวกับ ATTLIST และ ENTITY ไม่ว่าจะเป็นอะไรก็ตาม

เรามาพูดถึงเรื่องนี้กันก่อนด้วยความอดทนเล็กน้อย

บรรทัดด้านบนอาจดูไม่ดี แต่จริงๆ แล้วไม่มีอะไรเลย ใช้ใน DTD เพื่อกำหนดแอตทริบิวต์และเอนทิตีในเอกสาร XML ใครก็ตามที่รู้ HTML จะรู้เรื่องนี้เป็นอย่างดี คุณลักษณะคือรายการที่มีแท็ก HTML ซึ่งอธิบายแท็กได้แม่นยำยิ่งขึ้น ใน <img src="my.gif" height="20" width="20"> ที่ปรากฏบ่อยครั้งจะมีแอตทริบิวต์อยู่ 2 ประการ ได้แก่ ความสูงและความกว้าง ดังที่คุณจะเห็นในภายหลัง การใช้แอตทริบิวต์ในเอกสาร XML จะคล้ายกันมาก

ไม่มีอะไรใหม่เกี่ยวกับเอนทิตีเช่นกัน หากคุณเคยใช้ & คุณก็รู้พื้นฐานแล้ว สตริงที่ล้อมรอบด้วย & และอัฒภาคแสดงถึงอักขระอื่นหรือชุดอักขระอื่น (มีรายการเอนทิตี ISO ทั้งหมดอยู่ที่นี่)

แน่นอนว่าแอตทริบิวต์และเอนทิตีใน XML มีฟังก์ชันอื่นๆ สิ่งนี้ทำให้เกิดไวยากรณ์อย่างหลีกเลี่ยงไม่ได้แม้ว่าจะไม่มากเกินไปก็ตาม เมื่อคุณรู้สิ่งนี้แล้ว การทำงานกับเอกสาร XML จะเป็นเรื่องง่าย

สูตรอาหารแบบง่าย

หากคุณอ่านบทนำของฉันเกี่ยวกับ XML คุณจะจำได้ว่าส่วนผสมในสูตรอาหารจะแสดงด้วยแท็กง่ายๆ เช่น <item>แป้ง 2 ถ้วย</item> หลังจากเขียนบทความนั้น ฉันก็ท่องเว็บและพบเอกสาร XML อีกฉบับเกี่ยวกับสูตรอาหาร องค์ประกอบของสูตรมีดังนี้:

<ingredient quantity="2" unit="cups">แป้ง</ingredient>

วิธีการนี้มีประโยชน์ในทางปฏิบัติ เนื่องจากทำให้ควบคุมข้อมูลได้ง่ายขึ้น ด้วยวิธีแรก แท็ก <item> ใช้เพื่อเก็บข้อมูลต่างๆ มากมาย ถ้าฉันต้องการแยกรายการส่วนผสมโดยไม่ระบุปริมาณของส่วนผสมแต่ละรายการ ฉันคงไม่ทำอย่างนั้น

ฉันสามารถบรรลุฟังก์ชันการทำงานที่คล้ายกันได้โดยใช้โครงสร้างต่อไปนี้:

<item>แป้ง

<ปริมาณ>2</quantity>

<หน่วย>ถ้วย</units>

สิ่งนี้สามารถจัดการได้ แต่มีปัญหาอยู่สองประการ ประการแรก องค์ประกอบรายการมีเนื้อหาผสม: ข้อความและมาร์กอัปอื่นๆ ฉันค้นพบอย่างรวดเร็วว่าควรหลีกเลี่ยงโครงสร้างนี้ทุกครั้งที่ทำได้ ประการที่สองคือเครื่องหมายแทบไม่มีความหมายที่เป็นอิสระ เป็นการยากที่จะจินตนาการถึงสถานการณ์ที่มีเพียงหน่วย แต่ไม่มีส่วนประกอบจริง รายการเหล่านี้สามารถอธิบายได้ง่าย ๆ ฉันชอบคิดว่ามันเป็นคุณสมบัติ

สิ่งแรกที่ควรทราบคือชื่อแอตทริบิวต์ ปริมาณ และหน่วยจะมีความหมายเมื่อประมวลผลโดยแอปพลิเคชันที่สามารถแปลได้เท่านั้น

ควรแจ้งให้ DTD อนุญาตก่อนที่จะรวมไว้ในเอกสารที่ถูกต้อง สำหรับองค์ประกอบส่วนผสมข้างต้น เราได้รวมเฉพาะโค้ดต่อไปนี้ใน DTD:

<!ELEMENT ส่วนผสม #PCDATA>

<!ATTLIST ปริมาณส่วนผสม CDATA #REQUIRED>

<!ATTLIST หน่วยส่วนผสม CDATA #REQUIRED>

บรรทัดแรกดูคุ้นเคย - คำจำกัดความองค์ประกอบมาตรฐานที่คุณจะเห็นใน DTD ใดๆ แต่ละบรรทัด ATTLIST จะมีข้อมูลต่อไปนี้ตามลำดับ:

<!ATTLIST ปริมาณส่วนผสม CDATA #REQUIRED>

นี่คือองค์ประกอบที่มีการแนบแอตทริบิวต์

<!ATTLIST ปริมาณส่วนผสม CDATA #REQUIRED>

ชื่อแอตทริบิวต์ถูกกำหนดไว้ที่นี่

<!ATTLIST ปริมาณส่วนผสม CDATA #REQUIRED>

กำหนดประเภทแอตทริบิวต์ที่นี่ CDATA ย่อมาจากข้อมูลอักขระ หมายความว่าโปรเซสเซอร์สามารถรับข้อความภายในแอตทริบิวต์ได้

<!ATTLIST ปริมาณส่วนผสม CDATA #REQUIRED>

ส่วนสุดท้ายจะกำหนดค่าเริ่มต้นของแอตทริบิวต์ คุณสามารถใช้ค่าตัวเลขจริงได้ เช่น 3 ด้วยวิธีนี้ ค่าแอตทริบิวต์สำหรับความยาวของช่องว่างใน XML จะเป็น 3 ค่าที่ป้อนจะแทนที่ค่าเริ่มต้น

ในตัวอย่างข้างต้น ฉันไม่ได้กำหนดปริมาณเฉพาะ แต่ใช้คีย์เวิร์ด XML #REQUIRED มันบอกโปรเซสเซอร์ว่าแอตทริบิวต์รองจะต้องมีค่า หากเว้นว่างไว้ เอกสารจะไม่ได้รับการประมวลผล

ค่าเริ่มต้นมีคำหลักเพิ่มเติมสองคำ ค่าแรกคือ #FIXED - หากค่าแอตทริบิวต์ยังคงเป็นค่าเดียวกันตลอดทั้งเอกสาร สมมติว่าฉันกำหนดแอตทริบิวต์แท็กรูปภาพ และรูปภาพทั้งหมดมีขนาดเท่ากัน เช่น 100*50 พิกเซล ฉันสามารถกำหนดแอตทริบิวต์เช่นนี้ใน DTD:

<!ATTLIST ความยาวของภาพ CDATA #FIXED "100 px">

<!ATTLIST ความกว้างของภาพ CDATA #FIXED "50 px">

คีย์เวิร์ดอีกคำหนึ่งคือ #IMPLIED ซึ่งบ่งชี้ว่าคุณสมบัติสามารถมีค่าหรือเว้นว่างได้

ลองดูที่ประเภทแอตทริบิวต์

หากคุณตัดสินใจที่จะเขียน DTD ของคุณเอง คุณอาจต้องการหนังสือที่อธิบาย XML ของชุดค่าผสมทั้งหมดในคำสั่ง ATTLIST แต่ถ้าคุณยืม DTD คุณจะรู้เพียง CDATA และคุณลักษณะอื่น ๆ อีกสามประการเท่านั้น

อันแรกคือไอดี กำหนดให้ไม่ต้องระบุค่าของแอตทริบิวต์ซ้ำในเอกสาร ใครก็ตามที่เคยใช้ฐานข้อมูลจะรู้ดีถึงความจำเป็นในการระบุตัวระบุเฉพาะ คำสั่ง DTD ATTLIST มีลักษณะดังนี้:

<!ATTLIST element_nameattribute_name ID #REQUIRED>

เป็นเรื่องยากที่จะจินตนาการถึงประเภทแอตทริบิวต์ ID ที่ไม่มีค่าเริ่มต้นเป็น #REQUIRED ในกรณีนั้น ID ที่ซ้ำกันหรือว่างเปล่าจะบังคับให้โปรเซสเซอร์ส่งคืนข้อผิดพลาด รหัสต้องขึ้นต้นด้วยตัวอักษรหรือขีดล่าง และต้องไม่มีการเว้นวรรค

ประเภท NMTOKEN ยังใช้กฎการตั้งชื่อข้างต้น แต่อนุญาตให้ทำซ้ำได้ มันถูกใช้เป็นการรับประกันในการส่งข้อมูลไปยังแอปพลิเคชัน ภาษาโปรแกรมส่วนใหญ่ รวมถึง Java และ JavaScript ไม่สามารถมีช่องว่างในชื่อโมดูลได้ ในกรณีส่วนใหญ่ วิธีที่ดีที่สุดคือต้องแน่ใจว่าพร็อพเพอร์ตี้ปฏิบัติตามกฎของตน

สุดท้ายนี้ มีประเภทการแจกแจงที่ไม่ต้องใช้คำหลักเฉพาะเจาะจง ให้ใช้สัญลักษณ์ "|" เพื่อใส่ค่าไว้ในวงเล็บแทน เช่น:

<!ATTLIST พี่น้อง (brother | sister) #REQUIRED>

สามารถใช้วิธีนี้ได้หากมีค่าแอตทริบิวต์ที่เป็นไปได้ในจำนวนจำกัด

คุณไม่คิดว่าหลักสูตรวันนี้น่าเบื่อ ดังนั้นโปรดอ่านต่อ!