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 개의 항목이있을 것입니다. 실제로 그들의 제안은 내가 제안한 것보다 3 배 더 큽니다. 나는 언급 된 신비한 "Industry Standard"를 검색했지만 XML 속성은 메타 데이터에만 사용해야한다는 것이지만 메타 데이터가 무엇인지에 대한 논쟁이었다.

메타 데이터가 무엇인지 어떻게 판단하고 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은 궁극적으로 필드 값이 속성으로 배치되는 데 효과적입니다.

그러나 메시지 전송으로 사용되는 XML은 종종 더 많은 요소를 사용하는 것이 좋습니다.

예를 들어 대답에서 제안 된 대로이 XML을 가지고 있다고 가정 해 보겠습니다.

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

이제 바코드를 인쇄하기 위해 ITEM 요소를 장치로 보내려고하지만 인코딩 유형을 선택할 수 있습니다. 필요한 인코딩 유형을 어떻게 표현합니까? 갑자기 우리는 바코드가 단일 자동 값이 아니라 인쇄 할 때 필요한 인코딩으로 규정 될 수 있음을 다소 뒤늦게 알고 있습니다.

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

요점은 석재 구조를 고정하기 위해 네임 스페이스와 함께 XSD 또는 DTD를 구축하지 않는 한 옵션을 열어 두는 것이 가장 좋습니다.

IMO XML은 기존 코드를 사용하지 않고 유연하게 조정할 수있을 때 가장 유용합니다.

속성 대 요소와 관련하여 스키마 디자인에서 다음 지침을 사용합니다.

• 오래 실행되는 텍스트 (보통 문자열 또는 normalString 유형의 요소)를 사용하십시오.
• 요소에 대해 두 개의 값 그룹 (예 : eventStartDate 및 eventEndDate)이있는 경우 속성을 사용하지 마십시오. 이전 예에는 startDate 및 endDate 속성을 포함 할 수있는 "event"에 대한 새 요소가 있어야합니다.
• 영업 날짜, 날짜 시간 및 숫자 (예 : 개수, 금액 및 비율)는 요소 여야합니다.
• 마지막 업데이트, 만료 등의 비업무 시간 요소는 속성이어야합니다.
• 해시 코드 및 인덱스와 같은 비업무 번호는 속성이어야합니다. * 유형이 복잡한 경우 요소를 사용하십시오.
• 값이 단순 유형이고 반복되지 않는 경우 속성을 사용하십시오.
• xml : id 및 xml : lang은 XML 스키마를 참조하는 속성이어야합니다.
• 기술적으로 가능한 경우 속성을 선호하십시오.

속성의 기본 설정은 다음을 제공합니다.

• 고유 (속성이 여러 번 나타날 수 없음)
• 순서는 중요하지 않습니다
• 위의 속성은 상속 가능합니다 (이것은 "모든"콘텐츠 모델이 현재 스키마 언어에서 지원하지 않는 것입니다)
• 보너스는 덜 장황하고 더 적은 대역폭을 사용한다는 것입니다. 그러나 실제로 요소보다 속성을 선호하는 이유는 아닙니다.

속성을 사용할 수없는 시간이 있기 때문에 기술적으로 가능한 경우 추가했습니다 . 예를 들어, 속성 세트 선택. 예를 들어, 현재 스키마 언어에서는 (startDate 및 endDate) xor (startTS 및 endTS)를 사용할 수 없습니다.

XML 스키마가 "모든"컨텐츠 모델의 제한 또는 확장을 허용하기 시작하면이를 삭제합니다.

의심 스러울 때 KISS- 속성을 사용해야 할 명확한 이유가 없을 때 속성과 요소를 혼합하는 이유. 나중에 XSD를 정의하기로 결정하면 결국 더 깨끗해질 것입니다. 그런 다음 나중에 XSD에서 클래스 구조를 생성하기로 결정하면 더 간단해질 것입니다.

이 질문에 대한 보편적 인 대답은 없습니다 (W3C 사양 작성에 크게 관여했습니다). XML은 여러 가지 목적으로 사용될 수 있습니다. 텍스트와 같은 문서, 데이터 및 선언적 코드가 가장 일반적입니다. 또한 데이터 모델로 많이 사용합니다. 속성이 더 일반적인 응용 프로그램과 자식 요소가 더 자연적인 응용 프로그램의 측면이 있습니다. 사용하기 쉽게 또는 더 어렵게하는 다양한 도구의 기능도 있습니다.

XHTML은 속성이 자연스럽게 사용되는 영역 중 하나입니다 (예 : class = 'foo'). 속성은 순서가 없으므로 일부 사람들이 도구를 쉽게 개발할 수 있습니다. OTOH 속성은 스키마없이 입력하기가 더 어렵습니다. 또한 네임 스페이스 속성 (foo : bar = "zork")이 다양한 도구 세트에서 관리하기가 더 어렵다는 것을 알았습니다. 그러나 W3C 언어 중 일부를 살펴보면 일반적인 혼합물을 볼 수 있습니다. SVG, XSLT, XSD, MathML은 잘 알려진 언어의 예이며 모두 풍부한 속성과 요소를 가지고 있습니다. 일부 언어는 단방향보다 더 많은 것을 허용합니다.

<foo title="bar"/>;

또는

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

이것들은 문법적으로 동등하지 않으며 처리 도구에서 명시 적 지원이 필요합니다)

본인의 조언은 응용 프로그램과 가장 가까운 영역에서 일반적인 관행을 살펴보고 적용 할 도구 세트를 고려하는 것입니다.

마지막으로 네임 스페이스와 속성을 구분해야합니다. 일부 XML 시스템 (예 : Linq)은 네임 스페이스를 API의 속성으로 나타냅니다. IMO 이것은 추악하고 혼란 스러울 수 있습니다.

다른 사람들은 속성과 요소를 구별하는 방법을 다루었지만 결과 XML을 작게 만들기 때문에 모든 것을 속성에 넣는보다 일반적인 관점에서 설명했습니다.

XML은 소형이 아니라 이식 가능하고 사람이 읽을 수 있도록 설계되었습니다. 전송중인 데이터의 크기를 줄이려면 Google 프로토콜 버퍼 와 같은 다른 것을 사용하십시오 .

백만 달러짜리 질문!

우선, 성능에 대해 너무 걱정하지 마십시오. 최적화 된 XML 파서가 XML을 얼마나 빨리 찢어 버릴지 놀랄 것입니다. 더 중요한 것은 미래의 디자인은 무엇입니까? XML이 발전함에 따라 어떻게 느슨한 결합과 상호 운용성을 유지할 수 있습니까?

보다 구체적으로, 요소의 컨텐츠 모델을 더 복잡하게 만들 수 있지만 속성을 확장하기가 더 어렵습니다.

객체의 속성을 저장하는 두 가지 방법 모두 완벽하게 유효합니다. 실제적인 고려 사항에서 벗어나야합니다. 다음 질문에 답하십시오.

1. 더 빠른 데이터 구문 분석 / 생성이 가능한 표현은 무엇입니까?

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 블록을 사용하여 요소를 분해 할 시간이라고 말합니다.

<?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; & amp; & quot; & apos;으로 각각 이스케이프해야합니다. XML 라이브러리를 사용하는 경우이를 대신 처리합니다.

지옥, 속성은 원하는 경우 이미지와 같은 이진 데이터를 base64로 인코딩하고 데이터 : URL로 만들 수 있습니다.

@feenster : IDS 또는 NAMES의 경우 숫자를 포함하여 공백으로 구분 된 여러 항목을 속성에 포함 할 수 있습니다. Nitpicky, 그러나 이것은 공간 절약으로 이어질 수 있습니다.

속성을 사용하면 XML과 JSON의 경쟁력을 유지할 수 있습니다. 지방 마크 업 : 지방 마크 업 신화를 한 번에 한 칼로리 씩 잘라 내기를 참조하십시오 .

나는 이런 종류의 토론의 결과에 항상 놀랐습니다. 나에게 데이터가 속성에 속하는지 또는 내용에 속하는지를 결정하는 매우 간단한 규칙이 있으며, 데이터에 탐색 가능한 하위 구조가 있는지 여부가 있습니다.

예를 들어 마크 업이 아닌 텍스트는 항상 속성에 속합니다. 항상.

리스트는 하위 구조 또는 컨텐츠에 속합니다. 시간이 지남에 따라 포함 된 구조화 된 하위 컨텐츠를 포함 할 수있는 텍스트는 컨텐츠에 속합니다. (제 경험상 데이터 저장 또는 교환에 XML을 사용할 때 마크 업이있는 텍스트는 거의 없습니다.)

이 방법으로 작성된 XML 스키마는 간결합니다.

내가 같은 경우를 볼 때마다 <car><make>Ford</make><color>Red</color></car>"저는 저자가 make 요소 내에 하위 요소가 있다고 생각 했습니까?"라고 생각합니다. <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>