แอตทริบิวต์ XML และองค์ประกอบ XML

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

ตัวอย่างที่ฉันคิดขึ้นมานั้นเป็นสิ่งที่ต้องการ:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

ทีมอื่นกล่าวว่านี่ไม่ใช่มาตรฐานอุตสาหกรรมและควรใช้แอตทริบิวต์นั้นกับข้อมูลเมตาเท่านั้น พวกเขาแนะนำ:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

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

หลังจากคำอธิบายที่ยืดยาว (ขอโทษ) คุณจะทราบได้อย่างไรว่าข้อมูล meta คืออะไรและเมื่อออกแบบโครงสร้างของเอกสาร XML คุณจะตัดสินใจได้อย่างไรว่าจะใช้แอตทริบิวต์หรือองค์ประกอบเมื่อใด

ฉันใช้กฎง่ายๆนี้:

1. แอททริบิวต์คือสิ่งที่มีอยู่ในตัวเองเช่นสีรหัส ID ชื่อ
2. องค์ประกอบคือสิ่งที่ทำหรืออาจมีแอตทริบิวต์ของตนเองหรือมีองค์ประกอบอื่น ๆ

ดังนั้นคุณอยู่ใกล้ ฉันจะทำสิ่งที่ชอบ:

แก้ไข : อัปเดตตัวอย่างต้นฉบับตามข้อเสนอแนะด้านล่าง

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

ปัญหาบางอย่างเกี่ยวกับคุณลักษณะคือ:

• คุณลักษณะต้องไม่มีค่าหลายค่า (องค์ประกอบย่อยสามารถ)
• แอตทริบิวต์ไม่สามารถขยายได้อย่างง่ายดาย (สำหรับการเปลี่ยนแปลงในอนาคต)
• แอตทริบิวต์ไม่สามารถอธิบายโครงสร้าง (องค์ประกอบย่อยสามารถ)
• คุณลักษณะจะยากต่อการจัดการโดยรหัสโปรแกรม
• ค่าแอตทริบิวต์ไม่ใช่เรื่องง่ายที่จะทดสอบกับ DTD

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

อย่าท้ายเรื่องนี้ (นี่ไม่ใช่วิธีการใช้ XML):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

ที่มา: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML" ย่อมาจาก "eXtensible Markup Language" ภาษามาร์กอัปแสดงว่าข้อมูลเป็นข้อความทำเครื่องหมายด้วยเมทาดาทาเกี่ยวกับโครงสร้างหรือการจัดรูปแบบ

XHTML เป็นตัวอย่างของ XML ที่ใช้ตามที่ตั้งใจไว้:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

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

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

องค์ประกอบ XML กับแอตทริบิวต์ XML

XML เป็นเรื่องเกี่ยวกับข้อตกลงทั้งหมด ก่อนอื่นให้เลื่อนไปที่สกีมา XML ที่มีอยู่หรืออนุสัญญาที่จัดตั้งขึ้นภายในชุมชนหรืออุตสาหกรรมของคุณ

หากคุณอยู่ในสถานการณ์อย่างแท้จริงเพื่อกำหนดสคีมาของคุณตั้งแต่แรกเริ่มนี่คือข้อควรพิจารณาทั่วไปที่ควรแจ้งการตัดสินใจองค์ประกอบกับแอตทริบิวต์ :

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

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

อย่างไรก็ตาม XML ที่ใช้เป็นการส่งข้อความมักจะดีกว่าเมื่อใช้องค์ประกอบเพิ่มเติม

ตัวอย่างเช่นสมมติว่าเรามี XML นี้ตามที่เสนอในคำตอบ: -

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

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

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

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

IMO XML มีประโยชน์สูงสุดเมื่อสามารถยืดหยุ่นได้โดยไม่ทำให้โค้ดที่มีอยู่เสียหาย

ฉันใช้แนวทางต่อไปนี้ในการออกแบบคีมาของฉันเกี่ยวกับคุณลักษณะและองค์ประกอบ:

• ใช้องค์ประกอบสำหรับข้อความที่ยาว (โดยปกติแล้วจะเป็นสตริงหรือประเภท normalizedString)
• อย่าใช้แอตทริบิวต์หากมีการจัดกลุ่มของสองค่า (เช่น eventStartDate และ eventEndDate) สำหรับองค์ประกอบ ในตัวอย่างก่อนหน้านี้ควรมีองค์ประกอบใหม่สำหรับ "เหตุการณ์" ซึ่งอาจมีแอตทริบิวต์ startDate และ endDate
• วันที่ธุรกิจ, DateTime และตัวเลข (เช่นจำนวน, จำนวนและอัตรา) ควรเป็นองค์ประกอบ
• องค์ประกอบเวลาที่ไม่ใช่ธุรกิจเช่นการอัปเดตล่าสุดการหมดอายุควรเป็นแอตทริบิวต์
• หมายเลขที่ไม่ใช่ธุรกิจเช่นรหัสแฮชและดัชนีควรเป็นแอตทริบิวต์ * ใช้องค์ประกอบหากประเภทจะซับซ้อน
• ใช้แอ็ตทริบิวต์ถ้าค่าเป็นประเภทแบบง่ายและไม่ทำซ้ำ
• xml: id และ xml: lang ต้องเป็นแอตทริบิวต์ที่อ้างอิง XML schema
• ชอบแอตทริบิวต์เมื่อทำได้ทางเทคนิค

การตั้งค่าสำหรับคุณลักษณะมันมีดังต่อไปนี้:

• ไม่ซ้ำกัน (แอตทริบิวต์ไม่สามารถปรากฏได้หลายครั้ง)
• คำสั่งไม่สำคัญ
• คุณสมบัติด้านบนสามารถสืบทอดได้ (นี่คือสิ่งที่โมเดลเนื้อหา "all" ไม่สนับสนุนในภาษาสคีมาปัจจุบัน)
• โบนัสคือพวกเขาให้รายละเอียดน้อยลงและใช้แบนด์วิดท์น้อยลง แต่นั่นไม่ใช่เหตุผลที่จะชอบคุณลักษณะมากกว่าองค์ประกอบ

ฉันเพิ่มเมื่อเป็นไปได้ทางเทคนิคเพราะมีหลายครั้งที่ไม่สามารถใช้คุณลักษณะได้ ตัวอย่างเช่นตัวเลือกชุดคุณลักษณะ ตัวอย่างเช่นการใช้ (startDate และ endDate) xor (startTS และ endTS) เป็นไปไม่ได้ด้วยภาษาสคีมาปัจจุบัน

หาก XML Schema เริ่มอนุญาตให้โมเดลเนื้อหา "ทั้งหมด" ถูก จำกัด หรือขยายดังนั้นฉันอาจจะวาง

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

ไม่มีคำตอบที่เป็นสากลสำหรับคำถามนี้ (ฉันมีส่วนร่วมอย่างมากในการสร้างข้อมูลจำเพาะ W3C) XML สามารถใช้เพื่อวัตถุประสงค์มากมาย - เอกสารที่มีลักษณะคล้ายข้อความข้อมูลและรหัสการประกาศมีสามอย่างที่พบบ่อยที่สุด ฉันยังใช้มันเป็นแบบจำลองข้อมูลมาก มีแง่มุมต่าง ๆ ของแอปพลิเคชั่นเหล่านี้ที่มีคุณสมบัติทั่วไปและส่วนอื่น ๆ ที่องค์ประกอบย่อยเป็นธรรมชาติมากกว่า นอกจากนี้ยังมีคุณสมบัติของเครื่องมือต่าง ๆ ที่ทำให้ใช้งานได้ง่ายขึ้นหรือยากขึ้น

XHTML เป็นพื้นที่หนึ่งที่แอตทริบิวต์มีการใช้งานตามธรรมชาติ (เช่นใน class = 'foo') คุณสมบัติไม่มีคำสั่งซื้อและอาจทำให้บางคนพัฒนาเครื่องมือได้ง่ายขึ้น แอตทริบิวต์ OTOH นั้นยากที่จะพิมพ์โดยไม่มีสคีมา ฉันยังพบว่าแอตทริบิวต์ namespaced (foo: bar = "zork") มักจะจัดการได้ยากในชุดเครื่องมือต่างๆ แต่ดูที่ภาษา W3C บางภาษาเพื่อดูส่วนผสมที่เป็นเรื่องธรรมดา SVG, XSLT, XSD, MathML เป็นตัวอย่างบางส่วนของภาษาที่รู้จักกันดีและทั้งหมดมีคุณสมบัติและองค์ประกอบมากมาย บางภาษาอนุญาตให้ทำได้มากกว่าหนึ่งทางเช่น

<foo title="bar"/>;

หรือ

<foo>
  <title>bar</title>;
</foo>;

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

คำแนะนำของฉันคือการดูวิธีปฏิบัติทั่วไปในพื้นที่ที่ใกล้กับใบสมัครของคุณและพิจารณาชุดเครื่องมือที่คุณอาจต้องการใช้

ในที่สุดตรวจสอบให้แน่ใจว่าคุณแยกความแตกต่างของเนมสเปซจากแอตทริบิวต์ ระบบ XML บางระบบ (เช่น Linq) แสดงเนมสเปซเป็นคุณลักษณะใน API IMO นี้น่าเกลียดและอาจสับสน

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

XML ไม่ได้ถูกออกแบบมาให้มีขนาดกะทัดรัด แต่สามารถพกพาได้และมนุษย์สามารถอ่านได้ หากคุณต้องการลดขนาดของข้อมูลระหว่างทางให้ใช้อย่างอื่น (เช่นบัฟเฟอร์โปรโตคอลของ google )

คำถามล้านดอลลาร์!

ก่อนอื่นไม่ต้องกังวลเกี่ยวกับประสิทธิภาพมากเกินไป คุณจะประหลาดใจเมื่อเห็นว่าตัวแยกวิเคราะห์ xml ที่ปรับให้เหมาะสมนั้นจะตัดผ่าน xml ของคุณเร็วแค่ไหน ที่สำคัญกว่านั้นการออกแบบของคุณสำหรับอนาคตคืออะไร: ในขณะที่ XML มีวิวัฒนาการคุณจะรักษาข้อต่อและการทำงานร่วมกันได้อย่างไร

เป็นรูปธรรมมากขึ้นคุณสามารถทำให้รูปแบบเนื้อหาขององค์ประกอบที่ซับซ้อนมากขึ้น แต่มันก็ยากที่จะขยายคุณลักษณะ

ทั้งสองวิธีสำหรับการจัดเก็บคุณสมบัติของวัตถุนั้นถูกต้องสมบูรณ์ คุณควรออกจากการพิจารณาในทางปฏิบัติ ลองตอบคำถามต่อไปนี้:

1. การแสดงใดที่นำไปสู่การแยกวิเคราะห์ข้อมูล \ generation ที่เร็วขึ้น?

2. การแสดงใดที่นำไปสู่การถ่ายโอนข้อมูลที่เร็วขึ้น?

3. การอ่านมีความสำคัญหรือไม่

   ...

ใช้องค์ประกอบสำหรับข้อมูลและแอตทริบิวต์สำหรับข้อมูลเมตา (ข้อมูลเกี่ยวกับข้อมูลขององค์ประกอบ)

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

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

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

XML มีขนาดใหญ่มาก สำหรับการขนส่งและการเก็บรักษาขอแนะนำให้ใช้การบีบอัดหากคุณสามารถจ่ายกำลังการผลิตได้ XML บีบอัดได้ดีบางครั้งก็ดูดีเพราะมันมีการทำซ้ำ ฉันมีไฟล์ขนาดใหญ่บีบอัดให้เหลือน้อยกว่า 5% ของขนาดดั้งเดิม

อีกจุดหนึ่งที่สนับสนุนตำแหน่งของคุณคือในขณะที่ทีมอื่นกำลังโต้เถียงเกี่ยวกับสไตล์ (ในเครื่องมือ XML ส่วนใหญ่จะจัดการเอกสารคุณลักษณะทั้งหมดได้อย่างง่ายดายเหมือนกับเอกสาร PCDATA ทั้งหมด #) ที่คุณกำลังโต้เถียงกันจริง ในขณะที่สไตล์ไม่สามารถเพิกเฉยได้ แต่ข้อดีทางเทคนิคควรมีน้ำหนักมากกว่า

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

ตัวอย่างเช่นฉันชอบ .....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
         <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...แทน....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

อย่างไรก็ตามถ้าฉันมีข้อมูลที่ไม่ได้แสดงอย่างง่ายดายภายในตัวอักษร 20-30 ตัวหรือมีเครื่องหมายคำพูดหรือตัวละครอื่น ๆ ที่ต้องการหลบหนีฉันควรบอกว่าถึงเวลาที่จะแยกองค์ประกอบ ... อาจเป็นเพราะ CData block

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>

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

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

ฉันคิดว่าในกรณีที่ง่ายกว่าเช่นในตัวอย่างการวางแนวของวัตถุการเปรียบเทียบการทำงานก็โอเคที่จะคิดออกซึ่งเป็นองค์ประกอบและซึ่งเป็นคุณลักษณะขององค์ประกอบ

เพียงแค่การแก้ไขสองถึงข้อมูลที่ไม่ดี:

@John Ballinger: แอตทริบิวต์สามารถมีข้อมูลตัวอักษรใด ๆ <> & "'ต้องถูกหลบหนีไปที่ & lt; & gt; & amp; & quot; และ & apos;, ตามลำดับหากคุณใช้ห้องสมุด XML มันจะจัดการกับคุณ

Hell แอตทริบิวต์สามารถมีข้อมูลไบนารีเช่นรูปภาพหากคุณต้องการจริงๆเพียงแค่ทำการเข้ารหัส base64 และทำให้เป็นข้อมูล: URL

@feenster: แอตทริบิวต์สามารถมีหลายรายการคั่นด้วยช่องว่างในกรณีของ IDS หรือ NAMES ซึ่งจะรวมถึงตัวเลข Nitpicky แต่นี่อาจเป็นการประหยัดพื้นที่

การใช้คุณสมบัติสามารถแข่งขันกับ XML ด้วย JSON ดูMarkup ไขมัน: Trimming หนึ่งแคลอรี่ไขมัน Markup ตำนานในเวลา

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

ตัวอย่างเช่นข้อความที่ไม่ใช่มาร์กอัปอยู่ในแอตทริบิวต์เสมอ เสมอ.

รายการอยู่ในโครงสร้างย่อยหรือเนื้อหา ข้อความที่อาจใช้เวลานานรวมถึงเนื้อหาย่อยที่มีโครงสร้างที่ฝังอยู่ในเนื้อหา (จากประสบการณ์ของฉันมีค่อนข้างน้อย - ข้อความที่มีมาร์กอัป - เมื่อใช้ XML สำหรับการจัดเก็บข้อมูลหรือแลกเปลี่ยน)

XML schema ที่เขียนด้วยวิธีนี้รัดกุม

เมื่อใดก็ตามที่ฉันเห็นกรณีเช่น<car><make>Ford</make><color>Red</color></car>นี้ฉันคิดกับตัวเองว่า "ผู้เขียนไม่คิดว่าจะมีองค์ประกอบย่อยภายในองค์ประกอบสร้างหรือไม่" <car make="Ford" color="Red" />สามารถอ่านได้มากขึ้นอย่างมีนัยสำคัญไม่มีคำถามเกี่ยวกับวิธีการจัดการช่องว่าง ฯลฯ

ได้รับเพียง แต่กฎการจัดการช่องว่างฉันเชื่อว่านี่เป็นความตั้งใจที่ชัดเจนของนักออกแบบ XML

สิ่งนี้ชัดเจนมากใน HTML ซึ่งสามารถเห็นความแตกต่างของคุณลักษณะและมาร์กอัป:

1. ข้อมูลทั้งหมดอยู่ระหว่างมาร์กอัป
2. คุณสมบัติที่ใช้ในการอธิบายลักษณะของข้อมูลนี้ (เช่นรูปแบบ)

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

=> ข้อมูลส่วนใหญ่ควรอยู่ระหว่างมาร์กอัป

หากคุณต้องการใช้คุณลักษณะที่นี่: คุณสามารถแบ่งข้อมูลออกเป็นสองประเภท: ข้อมูลและ "ข้อมูลเมตา" โดยที่ข้อมูลเมตาไม่ได้เป็นส่วนหนึ่งของระเบียนคุณต้องการนำเสนอ แต่สิ่งต่าง ๆ เช่น "รูปแบบเวอร์ชัน", "วันที่สร้าง" ฯลฯ

<customer format="">
     <name></name>
     ...
</customer>

หนึ่งอาจกล่าวได้ว่า: "ใช้คุณลักษณะเพื่อกำหนดลักษณะแท็กใช้แท็กเพื่อให้ข้อมูลเอง"

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

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

เวลาเท่านั้นที่ฉันเคยใช้พวกเขาคือการกำหนดนามสกุลไฟล์ของ URL เนื้อหา:

<image type="gif">wank.jpg</image> ...etc etc

ฉันเดาว่าถ้าคุณรู้ 100% แอตทริบิวต์จะไม่จำเป็นต้องขยายคุณสามารถใช้พวกเขา แต่คุณรู้ว่ากี่ครั้ง

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>