XML 속성 또는 하위 노드 중에서 선택할 수있는 것은 무엇입니까?


15

데이터베이스의 일부 데이터를 XML로 내보내려고합니다. 예를 들어,이 Person할 수 있습니다 age, name그리고 몇몇 다른 속성.

XML 형식을 정의하기위한 두 가지 선택 사항이 있습니다.

선택 # 1 :

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

선택 # 2 :

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

하위 노드 또는 속성 정의의 차이점은 무엇입니까? 그리고 각 선택의 이점은 무엇입니까?



2
2008 년에 스택 오버플 로에 대해 요청 되었지만 , 이것은 디자인 결정으로 보이며 여기서 주제입니다.
토마스 오웬스

답변:


9

이에 대한 명확한 문서 / 모범 사례는 없지만 다음과 같이 대안을 고려하십시오.

요소 텍스트로 :

  • 텍스트를 마크 업 또는 메타 데이터가 아닌 텍스트로 간주하는 경우 xhtml 등으로 데이터를 표시하는 것이 더 쉬울 수 있습니다.
  • 둘 이상이있을 수 있습니다. 연령 또는 이름 행이 여러 개인 하위 콘텐츠가 필요한 경우 속성에서이를 허용하지 않습니다.
  • 행 레벨 메타 데이터가 필요한 경우 <name>또는 <age>이를 위해 속성을 사용하는 옵션 이 있습니다.

속성으로 :

  • XML이 더 컴팩트하다
  • XSLT 및 DocTypes를 지정하는 것이 더 간단합니다.
  • 공백 (패딩, 들여 쓰기, 줄 바꿈) 또는 PCDATA 영역 (요소 텍스트)에 도입 할 수있는 주석 (설명, PI)에 대해 걱정할 필요가 없습니다.
  • 단 하나만있을 수있다! 여러 age속성을 포함하는 하위 컨텐츠에 대해 걱정할 필요가 없습니다 .

XML로 작업하는 데 많은 시간을 보냈으며 순수한 데이터 통신을 위해서는 가능할 때마다 속성을 사용해야합니다. XML이 프리젠 테이션에 사용될 가능성이있는 경우 (XSLT, xhtml 등), 텍스트 내용 (더 나은 것은 아님)으로 더 나을 수 있습니다.


2
XSLT를 사용하려는 경우 문자 그대로 속성을 사용하지 않을 이유가 없습니다. XML + CSS 작업을하거나 다른 사람의 XSLT를 사용하려고한다면 ...
DougM

나는 당신의 좋은 답변을 조금 더 균형있게 만들기 위해 몇 가지 요점을 추가했습니다.
Doc Brown

9

XML 디자인의 원칙 : IBM의 Uche Ogbuji 가 제공하는 요소와 속성을 사용하는시기 는 아마도이 문제에 대한 최고의 리소스 중 하나 일 것입니다.

결정의 핵심은 속성이 '완료된 것'입니다. 변경하거나 수정하거나 중첩 할 수 없습니다. 순서는 독립적이며 요소 내에서 구별됩니다 (같은 것을 두 개 가질 수는 없습니다).

이러한 제약 조건 중 하나라도 변경 될 수있는 경우 데이터를 XML의 자식 노드로 만듭니다.

예를 들어, 이름과 나이를 가진 사람이 있습니다. 이름, 중간 이름, 성이 있고 닉네임이 있습니다. 그리고 어떤 사람들은 처녀 이름, 여러 개의 중간 이름 또는 명예를 가지고 있습니다. 어떻게 존 로널드 Reuel Tolkien 을 그러한 구조에 넣을 것 입니까?

그래서 우리는 그들에게 명령을 내리는 중간 이름을 가진 사람이 있습니다. 이것은 속성이 최선의 선택이 아니라는 것을 분명히 보여 주어야합니다.

현재이 문서를 찾을 수는 없지만 위의 링크 된 문서에는 이름이 "미래 기사에서 마크 업으로 사람들의 이름 처리를 확장하기를 희망합니다"라고하는 약간의 생각이 필요하다는 진술이 있습니다. 누구든지 이것에 대한 단서를 가지고 있다면, 의견을 남기 거나이 자리에서 편집하십시오.

다른 한편으로, 나이는 다소 고정 된 구조를 가진 것입니다 (정수보다는 생일을 제안합니다). 이와 같이,이 정보를 잘 알려져 있고 이해 된 형식으로 나타내는 것은 속성에서 의미가 있습니다. 사람은 단 하나의 생일을 가지고 있으며 당신이 보존하고 싶은 '주문'이 없습니다.

Uche Ogbuji는 xml 형식을 올바르게 디자인하는 데있어 세 가지 핵심 원칙을 식별합니다. 다음은 위의 링크 된 문서에서 인용 된 것입니다.

  • 구조화 된 정보의 원칙
    정보가 구조화 된 형태로 표현되는 경우, 특히 구조가 확장 가능한 경우 요소를 사용하십시오. 반면에 : 정보가 원자 토큰으로 표시되는 경우 속성을 사용하십시오.
  • 가독성의 원칙 사람이
    정보를 읽고 이해하려는 경우 요소를 사용하십시오. 기계가 정보를 가장 쉽게 이해하고 소화하는 경우 속성을 사용하십시오.
  • 요소 / 속성 바인딩의 원칙
    다른 속성으로 값을 수정해야하는 경우 요소를 사용하십시오.

따라서 이름은 요소 여야합니다. 즉, 원자 토큰이 아닌 구조화 된 데이터이며 컴퓨터보다 사람이 읽을 가능성이 높으며 이름 자체의 다른 속성으로 수정 될 수 있습니다.

날짜는 속성이어야합니다.-원자 토큰 인 데이터이며, 사람보다 컴퓨터가 읽을 가능성이 높으며 ( 필요한 경우 사람이 선호하는 형식으로 변환 될 수 있음 ) 마지막으로 다른 사람이 수정할 가능성이 없습니다. 그들에 대한 속성.


2

rolfl의 또 다른 고려 사항은 필드 수입니다.
소수의 속성 이상이 엉망이되어 읽기 어려워집니다 (XML은 사람이 읽을 수 있기를 원하지만 프로그래머는 최소한 테스트하기 위해 그것을 원할 것입니다).

또한 시간이 지남에 따라 필드 중 하나의 데이터 구조가 변경 될 것으로 예상되면 속성으로 만들지 마십시오.
예를 들어, 이름 필드입니다. 아마도 미래에는 이것이 될 것입니다

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

이와 같은 일이 발생할 것으로 예상되면 속성으로 만들면 나중에 더 리팩토링 코드를 의미합니다.


이 좋은 점에 감사드립니다. 왜 "애트리뷰트를 만드는 것이 나중에 더 리팩토링 코드를 의미 하는가"?
ZijingWu

2

Persons 태그의 경우 Person 태그가 더있는 것이 일반적입니다. Person 목록에는 속성이 아닌 일부 엔티티가 있습니다.

이야기는 Person과 그 구성 요소에 따라 다릅니다. Person에는 이름이 포함되어 있지 않으므로 이름은 Person의 속성이므로 새 태그 대신 속성을 사용합니다. 태그는 주소와 같은 반복적 인 것들이있을 때 유용하며, 속성으로는 할 수 없습니다.

HTML 컨텍스트에서 생각하면 값이있는 이름 태그가 입력되지 않은 것입니까?

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.