Thuộc tính XML so với phần tử XML

Khi làm việc, chúng tôi được yêu cầu tạo các tệp XML để truyền dữ liệu sang một ứng dụng ngoại tuyến khác, sau đó sẽ tạo một tệp XML thứ hai để gửi lại để cập nhật một số dữ liệu của chúng tôi. Trong quá trình chúng tôi đã thảo luận với nhóm của ứng dụng khác về cấu trúc của tệp XML.

Mẫu mà tôi đã đưa ra về cơ bản là một cái gì đó như:

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

Nhóm khác nói rằng đây không phải là tiêu chuẩn công nghiệp và các thuộc tính chỉ nên được sử dụng cho dữ liệu meta. Họ đề nghị:

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

Lý do tôi đề xuất đầu tiên là kích thước của tệp được tạo nhỏ hơn nhiều. Sẽ có khoảng 80000 mặt hàng sẽ có trong tập tin trong quá trình chuyển. Gợi ý của họ trong thực tế hóa ra lớn gấp ba lần so với đề xuất của tôi. Tôi đã tìm kiếm "Tiêu chuẩn công nghiệp" bí ẩn đã được đề cập, nhưng gần nhất tôi có thể tìm thấy là các thuộc tính XML chỉ nên được sử dụng cho dữ liệu meta, nhưng cho biết cuộc tranh luận là về dữ liệu meta thực sự là gì.

Sau phần giải thích dài dòng (xin lỗi), làm thế nào để bạn xác định dữ liệu meta là gì và khi thiết kế cấu trúc của tài liệu XML, bạn nên quyết định khi nào nên sử dụng một thuộc tính hoặc một phần tử?

Tôi sử dụng quy tắc này:

1. Thuộc tính là một cái gì đó khép kín, nghĩa là màu sắc, ID, tên.
2. Một phần tử là một cái gì đó có hoặc có thể có các thuộc tính của riêng nó hoặc chứa các phần tử khác.

Vì vậy, của bạn là gần. Tôi đã làm một cái gì đó như:

EDIT : Cập nhật ví dụ ban đầu dựa trên phản hồi bên dưới.

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

Một số vấn đề với các thuộc tính là:

• thuộc tính không thể chứa nhiều giá trị (phần tử con có thể)
• các thuộc tính không dễ dàng mở rộng (cho các thay đổi trong tương lai)
• thuộc tính không thể mô tả cấu trúc (yếu tố con có thể)
• các thuộc tính khó thao tác hơn bằng mã chương trình
• giá trị thuộc tính không dễ kiểm tra đối với DTD

Nếu bạn sử dụng các thuộc tính làm vùng chứa dữ liệu, bạn sẽ có tài liệu khó đọc và bảo trì. Cố gắng sử dụng các yếu tố để mô tả dữ liệu. Chỉ sử dụng các thuộc tính để cung cấp thông tin không liên quan đến dữ liệu.

Đừng kết thúc như thế này (đây không phải là cách sử dụng XML):

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

Nguồn: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML" là viết tắt của " Ngôn ngữ đánh dấu có thể mở rộng ". Một ngôn ngữ đánh dấu ngụ ý rằng dữ liệu là văn bản, được đánh dấu bằng siêu dữ liệu về cấu trúc hoặc định dạng.

XHTML là một ví dụ về XML được sử dụng theo cách nó được dự định:

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

Ở đây, sự phân biệt giữa các yếu tố và thuộc tính là rõ ràng. Các thành phần văn bản được hiển thị trong trình duyệt và các thuộc tính là hướng dẫn về cách hiển thị chúng (mặc dù có một số thẻ không hoạt động theo cách đó).

Nhầm lẫn phát sinh khi XML được sử dụng không phải là ngôn ngữ đánh dấu, mà là ngôn ngữ tuần tự hóa dữ liệu , trong đó sự phân biệt giữa "dữ liệu" và "siêu dữ liệu" là mơ hồ hơn. Vì vậy, sự lựa chọn giữa các yếu tố và thuộc tính ít nhiều tùy ý ngoại trừ những thứ không thể được biểu diễn bằng các thuộc tính (xem câu trả lời của feenster).

Phần tử XML so với thuộc tính XML

XML là tất cả về thỏa thuận. Đầu tiên trì hoãn mọi lược đồ XML hiện có hoặc các quy ước được thiết lập trong cộng đồng hoặc ngành của bạn.

Nếu bạn thực sự ở trong một tình huống để xác định lược đồ của bạn từ đầu, đây là một số cân nhắc chung cần thông báo cho phần tử và quyết định thuộc tính :

<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>

Nó có thể phụ thuộc vào cách sử dụng của bạn. XML được sử dụng để biểu diễn dữ liệu được sắp xếp được tạo từ cơ sở dữ liệu có thể hoạt động tốt với các giá trị trường cuối cùng được đặt làm thuộc tính.

Tuy nhiên, XML được sử dụng làm truyền tải thông điệp thường sẽ tốt hơn khi sử dụng nhiều phần tử hơn.

Ví dụ: giả sử chúng tôi có XML này như được đề xuất trong câu trả lời: -

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

Bây giờ chúng tôi muốn gửi phần tử ITEM đến một thiết bị để in mã vạch, tuy nhiên có một sự lựa chọn về các loại mã hóa. Làm thế nào để chúng tôi đại diện cho loại mã hóa cần thiết? Đột nhiên, chúng tôi nhận ra, hơi muộn màng, rằng mã vạch không phải là một giá trị tự động duy nhất mà là nó có thể đủ tiêu chuẩn với mã hóa cần thiết khi được in.

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

Vấn đề là trừ khi bạn xây dựng một số loại XSD hoặc DTD cùng với một không gian tên để sửa cấu trúc trong đá, bạn có thể được phục vụ tốt nhất để mở các tùy chọn của mình.

IMO XML là hữu ích nhất khi nó có thể được uốn mà không phá vỡ mã hiện có bằng cách sử dụng nó.

Tôi sử dụng các hướng dẫn sau trong thiết kế lược đồ của mình liên quan đến các thuộc tính so với các phần tử:

• Sử dụng các phần tử cho văn bản chạy dài (thường là các kiểu thuộc loại chuỗi hoặc normalizedString)
• Không sử dụng một thuộc tính nếu có nhóm hai giá trị (ví dụ: eventStartDate và eventEndDate) cho một phần tử. Trong ví dụ trước, cần có một phần tử mới cho "sự kiện" có thể chứa các thuộc tính startDate và endDate.
• Ngày kinh doanh, DateTime và số (ví dụ: số lượng, số lượng và tỷ lệ) phải là các yếu tố.
• Các yếu tố thời gian không kinh doanh như cập nhật lần cuối, hết hạn phải là thuộc tính.
• Các số không phải là doanh nghiệp như mã băm và chỉ mục phải là thuộc tính. * Sử dụng các phần tử nếu loại sẽ phức tạp.
• Sử dụng các thuộc tính nếu giá trị là một loại đơn giản và không lặp lại.
• xml: id và xml: lang phải là các thuộc tính tham chiếu lược đồ XML
• Thích các thuộc tính khi có thể về mặt kỹ thuật.

Các ưu tiên cho các thuộc tính là nó cung cấp như sau:

• duy nhất (thuộc tính không thể xuất hiện nhiều lần)
• thứ tự không quan trọng
• các thuộc tính trên có thể kế thừa (đây là điều mà mô hình nội dung "tất cả" không hỗ trợ trong ngôn ngữ lược đồ hiện tại)
• Phần thưởng là chúng ít dài dòng hơn và sử dụng ít băng thông hơn, nhưng đó không thực sự là lý do để thích các thuộc tính hơn các yếu tố.

Tôi đã thêm vào khi có thể về mặt kỹ thuật bởi vì có những lúc không thể sử dụng các thuộc tính. Ví dụ, lựa chọn tập thuộc tính. Ví dụ: không thể sử dụng xor (startDate và endDate) (startTS và endTS) với ngôn ngữ lược đồ hiện tại

Nếu Lược đồ XML bắt đầu cho phép mô hình nội dung "tất cả" bị hạn chế hoặc mở rộng thì có lẽ tôi sẽ bỏ nó

Khi nghi ngờ, KISS - tại sao trộn các thuộc tính và thành phần khi bạn không có lý do rõ ràng để sử dụng thuộc tính. Nếu sau này bạn quyết định xác định XSD, điều đó cũng sẽ sạch hơn. Sau đó, nếu bạn thậm chí sau đó quyết định tạo cấu trúc lớp từ XSD của mình, điều đó cũng sẽ đơn giản hơn.

Không có câu trả lời chung cho câu hỏi này (tôi đã tham gia rất nhiều vào việc tạo ra thông số W3C). XML có thể được sử dụng cho nhiều mục đích - tài liệu giống như văn bản, dữ liệu và mã khai báo là ba trong số phổ biến nhất. Tôi cũng sử dụng nó rất nhiều như một mô hình dữ liệu. Có những khía cạnh của các ứng dụng này, nơi các thuộc tính phổ biến hơn và các khía cạnh khác trong đó các phần tử con tự nhiên hơn. Ngoài ra còn có các tính năng của các công cụ khác nhau giúp sử dụng chúng dễ dàng hơn hoặc khó hơn.

XHTML là một khu vực nơi các thuộc tính có cách sử dụng tự nhiên (ví dụ: trong lớp = 'foo'). Các thuộc tính không có thứ tự và điều này có thể giúp một số người dễ dàng phát triển các công cụ hơn. Các thuộc tính OTOH khó nhập hơn nếu không có lược đồ. Tôi cũng thấy các thuộc tính được đặt tên (foo: bar = "zork") thường khó quản lý hơn trong các bộ công cụ khác nhau. Nhưng hãy xem một số ngôn ngữ W3C để thấy hỗn hợp phổ biến. SVG, XSLT, XSD, MathML là một số ví dụ về các ngôn ngữ nổi tiếng và tất cả đều có nguồn cung cấp các thuộc tính và thành phần phong phú. Một số ngôn ngữ thậm chí cho phép nhiều hơn một cách để làm điều đó, ví dụ:

<foo title="bar"/>;

hoặc là

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

Lưu ý rằng những cái này KHÔNG tương đương về mặt cú pháp và yêu cầu hỗ trợ rõ ràng trong các công cụ xử lý)

Lời khuyên của tôi là hãy nhìn vào thực tiễn phổ biến trong khu vực gần ứng dụng của bạn nhất và cũng xem xét những bộ công cụ nào bạn có thể muốn áp dụng.

Cuối cùng hãy chắc chắn rằng bạn phân biệt các không gian tên với các thuộc tính. Một số hệ thống XML (ví dụ Linq) biểu thị các không gian tên làm thuộc tính trong API. IMO này là xấu xí và có khả năng gây nhầm lẫn.

Những người khác đã đề cập đến cách phân biệt giữa các thuộc tính với các thành phần nhưng từ góc độ tổng quát hơn đặt mọi thứ vào thuộc tính vì nó làm cho kết quả XML nhỏ hơn là sai.

XML không được thiết kế nhỏ gọn mà có thể mang theo và có thể đọc được. Nếu bạn muốn giảm kích thước của dữ liệu trong quá trình thì hãy sử dụng một cái gì đó khác (chẳng hạn như bộ đệm giao thức của google ).

Câu hỏi triệu đô!

Trước hết, đừng lo lắng quá nhiều về hiệu suất bây giờ. bạn sẽ ngạc nhiên khi thấy trình phân tích cú pháp xml được tối ưu hóa sẽ nhanh chóng chuyển qua xml của bạn. quan trọng hơn, thiết kế của bạn trong tương lai là gì: khi XML phát triển, bạn sẽ duy trì khả năng khớp nối và khả năng tương tác lỏng lẻo như thế nào?

cụ thể hơn, bạn có thể làm cho mô hình nội dung của một yếu tố phức tạp hơn nhưng việc mở rộng một thuộc tính khó hơn.

Cả hai phương thức để lưu trữ các thuộc tính của đối tượng là hoàn toàn hợp lệ. Bạn nên khởi hành từ những cân nhắc thực dụng. Hãy thử trả lời câu hỏi sau:

1. Đại diện nào dẫn đến phân tích dữ liệu nhanh hơn \ thế hệ?

2. Đại diện nào dẫn đến truyền dữ liệu nhanh hơn?

3. Có dễ đọc không?

   ...

Sử dụng các yếu tố cho dữ liệu và thuộc tính cho dữ liệu meta (dữ liệu về dữ liệu của thành phần).

Nếu một phần tử hiển thị dưới dạng một vị ngữ trong chuỗi chọn của bạn, bạn có một dấu hiệu tốt cho thấy đó phải là một thuộc tính. Tương tự như vậy nếu một thuộc tính không bao giờ được sử dụng làm vị ngữ, thì có thể đó không phải là dữ liệu meta hữu ích.

Hãy nhớ rằng XML được coi là máy có thể đọc được chứ không phải con người có thể đọc được và đối với các tài liệu lớn, XML nén rất tốt.

Dù có thể tranh cãi theo cách nào, nhưng các đồng nghiệp của bạn đã hiểu đúng rằng XML nên được sử dụng cho "đánh dấu" hoặc siêu dữ liệu xung quanh dữ liệu thực tế. Về phần bạn, bạn nói đúng rằng đôi khi rất khó để quyết định ranh giới giữa dữ liệu meta và dữ liệu là gì khi mô hình hóa miền của bạn trong XML. Trong thực tế, những gì tôi làm là giả vờ rằng bất cứ điều gì trong đánh dấu đều bị ẩn và chỉ có dữ liệu bên ngoài đánh dấu là có thể đọc được. Liệu tài liệu có ý nghĩa theo cách đó?

XML nổi tiếng là cồng kềnh. Đối với vận chuyển và lưu trữ, nén rất được khuyến khích nếu bạn có đủ khả năng xử lý. XML nén tốt, đôi khi rất tốt, vì tính lặp lại của nó. Tôi đã có các tệp lớn nén xuống dưới 5% kích thước ban đầu của chúng.

Một điểm khác để củng cố vị trí của bạn là trong khi nhóm khác đang tranh luận về phong cách (trong đó hầu hết các công cụ XML sẽ xử lý một tài liệu thuộc tính tất cả dễ dàng như một tài liệu PCDATA), bạn đang tranh luận về tính thực tiễn. Mặc dù phong cách không thể hoàn toàn bị bỏ qua, nhưng giá trị kỹ thuật sẽ mang nhiều trọng lượng hơn.

Đó chủ yếu là vấn đề ưu tiên. Tôi sử dụng các yếu tố để nhóm và các thuộc tính cho dữ liệu khi có thể vì tôi thấy nó nhỏ gọn hơn so với giải pháp thay thế.

Ví dụ tôi thích .....

<?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>

...Thay vì....

<?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>

Tuy nhiên, nếu tôi có dữ liệu không thể hiện dễ dàng bên trong khoảng 20-30 ký tự hoặc chứa nhiều trích dẫn hoặc các ký tự khác cần thoát thì tôi đã nói rằng đã đến lúc phá vỡ các yếu tố ... có thể bằng các khối CData.

<?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>

Làm thế nào về việc tận dụng trực giác định hướng đối tượng khó kiếm của chúng tôi? Tôi thường thấy nó là thẳng về phía trước để nghĩ đó là một đối tượng và đó là một thuộc tính của đối tượng hoặc đối tượng mà nó đang đề cập đến.

Bất cứ điều gì trực giác có ý nghĩa như các đối tượng sẽ phù hợp như là các yếu tố. Các thuộc tính (hoặc thuộc tính) của nó sẽ là các thuộc tính cho các phần tử này trong xml hoặc phần tử con có thuộc tính.

Tôi nghĩ đối với các trường hợp đơn giản hơn như trong ví dụ tương tự hướng đối tượng hoạt động ổn để tìm ra phần tử nào và thuộc tính nào của phần tử.

Chỉ cần một vài sửa chữa cho một số thông tin xấu:

@ John Ballinger: Các thuộc tính có thể chứa bất kỳ dữ liệu ký tự nào. <> & "'cần phải được thoát đến & lt; & gt; & amp; & quot; và & apos;, nếu bạn sử dụng thư viện XML, nó sẽ giải quyết vấn đề đó cho bạn.

Địa ngục, một thuộc tính có thể chứa dữ liệu nhị phân như hình ảnh, nếu bạn thực sự muốn, chỉ bằng cách mã hóa cơ sở64 và biến nó thành dữ liệu: URL.

@feenster: Các thuộc tính có thể chứa nhiều mục được phân tách bằng dấu cách trong trường hợp IDS hoặc Nnam, bao gồm các số. Nitpicky, nhưng điều này có thể tiết kiệm không gian.

Sử dụng các thuộc tính có thể giữ XML cạnh tranh với JSON. Xem Fat Markup: Cắt giảm huyền thoại Fat Fatup một calo mỗi lần .

Tôi luôn ngạc nhiên về kết quả của những cuộc thảo luận này. Đối với tôi có một quy tắc rất đơn giản để quyết định liệu dữ liệu thuộc về một thuộc tính hay là nội dung và đó là liệu dữ liệu có cấu trúc phụ có thể điều hướng được hay không.

Vì vậy, ví dụ, văn bản không đánh dấu luôn thuộc về các thuộc tính. Luôn luôn.

Danh sách thuộc cấu trúc phụ hoặc nội dung. Văn bản có thể theo thời gian bao gồm nội dung phụ có cấu trúc nhúng thuộc về nội dung. (Theo kinh nghiệm của tôi, có khá ít điều này - văn bản có đánh dấu - khi sử dụng XML để lưu trữ hoặc trao đổi dữ liệu.)

Lược đồ XML được viết theo cách này là súc tích.

Bất cứ khi nào tôi thấy các trường hợp như thế <car><make>Ford</make><color>Red</color></car>, tôi nghĩ rằng "tác giả đã nghĩ rằng sẽ có các yếu tố phụ trong yếu tố tạo nên?" <car make="Ford" color="Red" />dễ đọc hơn đáng kể, không có câu hỏi nào về cách xử lý khoảng trắng, v.v.

Chỉ đưa ra nhưng các quy tắc xử lý khoảng trắng, tôi tin rằng đây là mục đích rõ ràng của các nhà thiết kế XML.

Điều này rất rõ ràng trong HTML nơi có thể thấy rõ sự khác biệt của các thuộc tính và đánh dấu:

1. Tất cả dữ liệu nằm giữa đánh dấu
2. Các thuộc tính được sử dụng để mô tả dữ liệu này (ví dụ: định dạng)

Nếu bạn chỉ có dữ liệu thuần túy như XML, có một sự khác biệt ít rõ ràng hơn. Dữ liệu có thể đứng giữa đánh dấu hoặc là thuộc tính.

=> Hầu hết dữ liệu nên đứng giữa đánh dấu.

Nếu bạn muốn sử dụng các thuộc tính ở đây: Bạn có thể chia dữ liệu thành hai loại: Dữ liệu và "dữ liệu meta", trong đó dữ liệu meta không phải là một phần của bản ghi, bạn muốn trình bày, nhưng những thứ như "phiên bản định dạng", "ngày tạo" , Vân vân.

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

Người ta cũng có thể nói: "Sử dụng các thuộc tính để mô tả thẻ, sử dụng thẻ để cung cấp dữ liệu."

Tôi đồng ý với feenster. Tránh xa các thuộc tính nếu bạn có thể. Các yếu tố thân thiện với sự tiến hóa và khả năng tương tác nhiều hơn giữa các bộ công cụ dịch vụ web. Bạn sẽ không bao giờ tìm thấy các bộ công cụ này nối tiếp các thông điệp yêu cầu / phản hồi của bạn bằng các thuộc tính. Điều này cũng có ý nghĩa vì các thông điệp của chúng tôi là dữ liệu (không phải siêu dữ liệu) cho bộ công cụ dịch vụ web.

Các thuộc tính có thể dễ dàng trở nên khó quản lý theo thời gian tin tưởng tôi. Tôi luôn tránh xa họ. Các yếu tố rõ ràng hơn và có thể đọc / sử dụng được bởi cả trình phân tích cú pháp và người dùng.

Chỉ có thời gian tôi từng sử dụng chúng là để xác định phần mở rộng tệp của url tài sản:

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

Tôi đoán nếu bạn biết 100% thuộc tính sẽ không cần phải mở rộng, bạn có thể sử dụng chúng, nhưng bạn biết điều đó bao nhiêu lần.

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