Chọn cái nào: Thuộc tính XML hoặc nút Sub?

Chúng tôi muốn xuất một số dữ liệu từ cơ sở dữ liệu của chúng tôi dưới dạng XML. Ví dụ, một Personcó thể có age, namevà một số thuộc tính khác.

Chúng tôi có hai lựa chọn để xác định định dạng XML.

Lựa chọn số 1:

<Persons>
   <Person>
       <Age>16</Age>
       <Name>Richard</Name>
   </Person>
   <Person>
       <Age>34</Age>
       <Name>Eric</Name>
   </Person>
   ...
</Persons>

Lựa chọn số 2:

<Persons>
   <Person Age="16" Name="Richard"/>
   <Person Age="34" Name="Eric"/>
   ...
</Persons>

Vì vậy, sự khác biệt giữa định nghĩa của nút phụ hoặc thuộc tính là gì? Và lợi ích của mỗi lựa chọn là gì?

Không có tài liệu rõ ràng / thực hành tốt nhất cho việc này, nhưng, hãy xem xét các lựa chọn thay thế, như bạn có:

Như văn bản phần tử:

• có thể dễ dàng hơn để hiển thị dữ liệu dưới dạng xhtml, v.v., trong đó nội dung văn bản được coi là văn bản, thay vì đánh dấu hoặc siêu dữ liệu.
• có thể có nhiều hơn một. Nếu bạn cần nội dung con có nhiều hàng tuổi hoặc tên, thuộc tính sẽ không cho phép điều này
• nếu bạn cần dữ liệu meta cấp hàng, bạn có tùy chọn sử dụng các thuộc tính của <name>hoặc <age>cho mục đích này

Như các thuộc tính:

• XML nhỏ gọn hơn
• XSLT và DocTypes đơn giản hơn để chỉ định
• bạn không phải lo lắng về khoảng trắng (phần đệm, thụt lề, ngắt dòng) hoặc các mục khác có thể được giới thiệu (nhận xét, PI) trong các khu vực PCDATA (văn bản phần tử)
• Có thể chỉ có một! bạn không phải lo lắng về nội dung con chứa nhiều agethuộc tính.

Tôi đã dành rất nhiều thời gian để làm việc với XML và, theo tôi, để giao tiếp dữ liệu thuần túy, các thuộc tính nên được sử dụng bất cứ khi nào có thể. Nếu XML có khả năng được sử dụng để trình bày (XSLT, xhtml, v.v.) thì nó có thể tốt hơn dưới dạng nội dung văn bản (nhưng không nhất thiết).

Nguyên tắc thiết kế XML: Khi nào sử dụng các yếu tố so với các thuộc tính của Uche Ogbuji từ IBM có lẽ là một trong những tài nguyên tốt nhất về vấn đề này.

Cốt lõi của quyết định là các thuộc tính là những thứ 'được thực hiện'. Bạn không thể thay đổi chúng hoặc sửa đổi chúng hoặc lồng chúng. Chúng là thứ tự độc lập và khác biệt trong thành phần (bạn không thể có hai thứ giống nhau).

Nếu bất kỳ ràng buộc nào trong số này là những điều có thể thay đổi, hãy biến dữ liệu thành nút con của XML.

Trong ví dụ của bạn, bạn có một người có tên và tuổi. Tôi có họ, tên đệm và họ ... và một biệt danh. Và một số người có tên thời con gái, nhiều tên đệm hoặc kính ngữ - làm thế nào bạn đặt John Ronald Reuel Tolkien vào một cấu trúc như vậy?

Và vì vậy chúng tôi có một người có hai tên đệm có thứ tự cho họ. Điều này sẽ cho thấy rõ rằng không, một thuộc tính không phải là lựa chọn tốt nhất cho việc này.

_{Hiện tại tôi không thể tìm thấy nó, nhưng trong tài liệu được liên kết ở trên có một tuyên bố rằng tên là những thứ đòi hỏi một chút suy nghĩ dẫn đến "Tôi hy vọng sẽ mở rộng việc xử lý tên của mọi người trong một bài báo trong tương lai." Nếu bất cứ ai có một khách hàng tiềm năng về điều này, xin vui lòng để lại nhận xét hoặc chỉnh sửa nó vào vị trí này.}

Mặt khác, tuổi là thứ có cấu trúc khá cố định (tôi muốn đề xuất ngày sinh thay vì số nguyên). Như vậy, đại diện cho thông tin này trong một định dạng nổi tiếng và được hiểu có ý nghĩa trong một thuộc tính. Một người có một, và chỉ có một sinh nhật và không có "yêu cầu" nào mà bạn muốn giữ gìn.

Uche Ogbuji xác định ba nguyên tắc cốt lõi trong việc thiết kế đúng định dạng xml. Sau đây là những trích dẫn viết tắt từ tài liệu được liên kết ở trên.

• Nguyên tắc của thông tin có cấu trúc
  Nếu thông tin được thể hiện dưới dạng có cấu trúc, đặc biệt nếu cấu trúc có thể mở rộng, hãy sử dụng các yếu tố. Mặt khác: Nếu thông tin được thể hiện dưới dạng mã thông báo nguyên tử, hãy sử dụng các thuộc tính
• Nguyên tắc dễ đọc
  Nếu thông tin được đọc và hiểu bởi một người, hãy sử dụng các yếu tố. Nếu thông tin dễ hiểu và được tiêu hóa nhất bởi máy, hãy sử dụng các thuộc tính.
• Nguyên tắc liên kết phần tử / thuộc tính
  Sử dụng một phần tử nếu bạn cần giá trị của nó được sửa đổi bởi thuộc tính khác

Và vì vậy, các tên nên là các phần tử - chúng là dữ liệu có cấu trúc không phải là mã thông báo nguyên tử, chúng có khả năng được con người đọc hơn là máy tính và chúng có thể được sửa đổi bởi một thuộc tính khác trên chính tên đó.

Ngày phải là thuộc tính - chúng là dữ liệu là mã thông báo nguyên tử, chúng có khả năng được máy tính đọc nhiều hơn con người (và sau đó được chuyển thành định dạng ưa thích của con người nếu cần ) và cuối cùng chúng không thể bị sửa đổi bởi người khác thuộc tính trên chúng.

Một điều cần xem xét khác của beyong rolfl là số lượng các lĩnh vực.
Nhiều hơn một số ít thuộc tính trở thành một mớ hỗn độn và khó đọc (giả sử bạn muốn xml của mình có thể đọc được, nhưng với tư cách là một lập trình viên, bạn sẽ muốn làm điều đó để kiểm tra ít nhất).

Ngoài ra, nếu bạn mong muốn cấu trúc dữ liệu của một trong các trường thay đổi theo thời gian, đừng biến nó thành một thuộc tính.
Ví dụ, trường tên của bạn. Có lẽ trong tương lai điều này sẽ trở thành

<name>
  <firstName>George</firstName>
  <lastName>Orwell</lastName>
  <maidenName></maidenName>
  <nickName>Robert</nickName>
</name>

Nếu bạn mong đợi điều tương tự xảy ra, biến nó thành một thuộc tính có nghĩa là sẽ tái cấu trúc mã nhiều hơn sau này.

Đối với thẻ Người, việc có nhiều thẻ Người hơn là điều bình thường, điều đó có ý nghĩa, một danh sách Người có một số thực thể, không phải thuộc tính.

Câu chuyện là khác nhau cho Người và các thành phần của nó. Một người không chứa tên, tên đó là một thuộc tính của Người, vì vậy tôi sẽ gắn bó với các thuộc tính thay vì các thẻ mới. Thẻ rất hữu ích khi bạn có những thứ lặp đi lặp lại như Địa chỉ, bạn không thể làm điều đó với các thuộc tính.

Nếu chúng tôi nghĩ trong ngữ cảnh HTML, bạn không có đầu vào với thẻ tên có giá trị, phải không?