XML 특성 대 XML 요소

programing

XML 특성 대 XML 요소

testmans 2023. 9. 17. 12:11

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배나 더 큰 것으로 드러났습니다.언급된 의문의 '산업 표준'을 찾아봤지만, 가장 가까운 곳에서 찾을 수 있었던 것은 XML 속성은 메타 데이터에만 사용해야 한다는 것이었지만, 실제로 메타 데이터가 무엇인지에 대한 논의라고 말했습니다.

장황하게 설명한 후(미안합니다) 메타데이터가 무엇인지, XML 문서의 구조를 설계할 때 속성이나 요소를 언제 사용할지 어떻게 결정해야 합니까?

나는 이 경험칙을 사용합니다.

Attribute는 색상, ID, 이름과 같이 자체적으로 포함되는 것입니다.
요소는 고유의 속성을 갖거나 가질 수 있는 것 또는 다른 요소를 포함할 수 있는 것입니다.

그래서 당신은 가깝군요.나는 다음과 같은 일을 했을 것입니다.

편집: 아래 피드백을 기반으로 원래 예제를 업데이트했습니다.

  <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이 마크업 언어가 아니라 데이터 직렬화 언어로 사용될 때 혼란이 발생하는데, 이 언어에서 "데이터"와 "메타데이터"의 구분이 더욱 모호합니다.따라서 요소와 속성 사이의 선택은 속성으로 표현할 수 없는 것을 제외하고는 다소 자의적입니다(펜스터의 대답 참조).

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은 기존 코드를 깨지 않고 유연하게 사용할 수 있을 때 가장 유용합니다.

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

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

속성의 기본 설정은 다음을 제공한다는 것입니다.

unique(속성은 여러 번 나타날 수 없음)
순서는 상관없습니다
위의 속성은 상속할 수 있습니다(현재 스키마 언어에서 "all" 컨텐츠 모델이 지원하지 않는 것입니다).
추가적인 이점은 말이 적고 대역폭을 덜 사용한다는 것입니다. 하지만 그렇다고 해서 요소보다 속성을 선호할 이유는 없습니다.

속성 사용이 불가능할 때가 있기 때문에 기술적으로 가능할 때 추가했습니다.예를 들어, 속성 집합 선택사항입니다.예를 들어 (startDate 및 endDate) x 또는 (start)를 사용합니다.TS 및 엔드현재 스키마 언어로는 TS)를 사용할 수 없습니다.

XML 스키마가 "모든" 컨텐츠 모델을 제한하거나 확장할 수 있도록 허용하기 시작하면 아마 삭제할 것입니다.

의심스러울 때, KISS -- 속성을 사용할 명확한 이유가 없는데 왜 속성과 요소를 섞습니까?나중에 XSD를 정의하기로 결정하면 이 또한 더 깨끗해질 것입니다.그러면 나중에 XSD에서 클래스 구조를 생성하기로 결정한다면 그것도 더 간단해질 것입니다.

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

XHTML은 속성이 자연스럽게 사용되는 영역 중 하나입니다(예: 클래스='foo'에서).속성에는 순서가 없으므로 일부 사용자가 도구를 개발하는 것이 더 쉬워질 수 있습니다.OTOH 특성은 스키마가 없으면 입력하기가 더 어렵습니다.또한 네임스피드 속성(foo:bar="zork")은 다양한 툴셋에서 관리하기가 더 어려운 경우가 많습니다.하지만 W3C 언어 중 일부를 살펴봄으로써 일반적인 혼합물을 확인할 수 있습니다.SVG, XSLT, XSD, MathML은 잘 알려진 언어들의 일부 예들이고 모두 풍부한 속성들과 요소들을 가지고 있습니다.어떤 언어들은 심지어 한 가지 이상의 방법을 허용하기도 합니다.

<foo title="bar"/>;

아니면

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

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

애플리케이션에서 가장 가까운 곳에 있는 일반적인 작업 방식을 살펴보고 적용할 수 있는 도구 세트를 고려해 보는 것이 좋을 것 같습니다.

마지막으로 네임스페이스를 특성과 구별해야 합니다.일부 XML 시스템(예: Linq)은 네임스페이스를 API에서 속성으로 나타냅니다.IMO 이것은 추하고 잠재적으로 혼란스럽습니다.

다른 것들은 요소로부터 속성을 구별하는 방법을 다루었지만, 결과적인 XML을 더 작게 만들기 때문에 더 일반적인 관점에서 모든 것을 속성에 넣는 것은 잘못된 것입니다.

XML은 컴팩트하게 설계된 것이 아니라 휴대가 가능하고 사람이 읽을 수 있도록 설계되었습니다.전송 중인 데이터의 크기를 줄이려면 구글의 프로토콜 버퍼와 같은 다른 것을 사용합니다.

백만 달러짜리 질문!

일단 퍼포먼스에 대해서는 지금 너무 걱정하지 마시고요.최적화된 XML 파서가 xml을 얼마나 빨리 복사하는지를 보고 놀라게 될 것입니다. 더 중요한 것은, XML이 발전함에 따라 어떻게 느슨한 결합과 상호 운용성을 유지할 것인가 하는 것입니다.

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

개체의 속성을 저장하는 두 가지 방법 모두 완벽하게 유효합니다.당신은 실용적인 고려에서 벗어나야 합니다.다음 질문에 대답해 보십시오.

어떤 표현이 더 빠른 데이터 파싱\생성으로 이어집니까?
어떤 표현이 데이터 전송 속도 향상으로 이어집니까?
가독성이 중요합니까?

...

데이터에는 요소를 사용하고 메타데이터에는 속성을 사용합니다(요소의 데이터에 대한 데이터).

요소가 선택 문자열에 술어로 표시되는 경우 해당 요소가 속성이어야 한다는 좋은 신호가 표시됩니다.마찬가지로 속성이 술어로 사용되지 않는 경우 유용한 메타 데이터가 아닐 수도 있습니다.

XML은 사람이 읽을 수 없는 기계로 읽을 수 있어야 하며 큰 문서의 경우 XML 압축을 매우 잘 수행해야 합니다.

어느 쪽이든 논쟁의 여지가 있지만 XML이 실제 데이터를 중심으로 한 "마크업"이나 메타 데이터에 사용되어야 한다는 점에서 동료들의 의견은 옳습니다.XML로 도메인을 모델링할 때 메타 데이터와 데이터의 경계가 어디인지 결정하기가 어려운 경우가 있습니다. 실제로 제가 하는 일은 마크업 안에 있는 모든 것을 숨기고 마크업 밖의 데이터만 읽을 수 있는 척하는 것입니다.그런 식으로 그 문서가 말이 됩니까?

XML은 부피가 큰 것으로 악명이 높습니다.운반 및 보관의 경우 처리 능력이 여유가 있는 경우 압축을 사용하는 것이 좋습니다.XML은 반복성 때문에 잘 압축되기도 하지만 때로는 경이적으로 잘 압축됩니다.대용량 파일을 원래 크기의 5% 미만으로 압축했습니다.

여러분의 입장을 강화하는 또 다른 점은 (대부분의 XML 도구가 올#PCDATA 문서처럼 모든 속성의 문서를 쉽게 처리한다는 점에서) 다른 팀이 스타일에 대해 논쟁하고 있지만, 여러분은 실용성에 대해 논쟁하고 있다는 것입니다.스타일을 완전히 무시할 수는 없지만 기술적인 장점이 더 큰 비중을 차지해야 합니다.

그것은 주로 선호도의 문제입니다.Elements for grouping and attribute for data(대안)보다 compact(컴팩트)하다고 생각하기 때문에 가능한 경우 Elements(요소)를 사용합니다.

예를 들면..

<?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자의 내부에 쉽게 표현되지 않는 자료가 있거나 탈출해야 할 인용문이나 다른 문자들이 많이 포함되어 있다면, 이제는 요소들을 제거할 때라고 말하고 싶습니다.CD 데이터 블록을 사용할 수도 있습니다.

<?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 또는 속성이 있는 자식 요소의 이러한 요소에 대한 속성일 것입니다.

예제와 같은 간단한 경우에는 어떤 것이 요소이고 어떤 것이 요소의 속성인지 알아내는 것이 좋다고 생각합니다.

몇 가지 잘못된 정보에 대한 수정 사항입니다.

@존 발링거:속성에는 모든 문자 데이터가 포함될 수 있습니다.< > & " '는 각각 < > & & & & & 및 '로 탈출해야 합니다.XML 라이브러리를 사용하면 이를 대신 처리해 줄 것입니다.

속성은 이미지와 같은 이진 데이터를 포함할 수 있습니다. 정말 원한다면 base64로 인코딩하여 데이터 URL로 만드는 것만으로 가능합니다.

@feenster:IDS나 NAMES의 경우, 속성에는 공백으로 구분된 여러 항목이 포함될 수 있으며, 이 항목에는 숫자가 포함됩니다.하지만 이것은 결국 공간을 절약할 수 있습니다.

속성을 사용하면 XML과 JSON의 경쟁력을 유지할 수 있습니다.Fat Markup 참조: 뚱보 마크업 신화를 한 번에 한 칼로리씩 줄이는 것.

이는 HTML에서 속성과 마크업의 차이를 명확하게 알 수 있습니다.

모든 데이터가 마크업 사이에 있습니다.
속성은 이 데이터를 특성화하는 데 사용됩니다(예: 형식).

순수한 데이터를 XML로 가지고 있다면 그 차이는 덜 분명합니다.데이터는 마크업과 속성 사이에 있을 수 있습니다.

=> 대부분의 데이터는 마크업 사이에 있어야 합니다.

여기서 특성을 사용하려는 경우: 데이터를 두 가지 범주로 나눌 수 있습니다.데이터 및 "메타 데이터"는 메타 데이터가 레코드의 일부가 아닌 "형식 버전", "만든 날짜" 등입니다.

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

"속성을 사용하여 태그를 특성화하고 태그를 사용하여 데이터 자체를 제공합니다."라고 말할 수도 있습니다.

저는 이런 종류의 토론의 결과에 항상 놀랍니다.저에게는 데이터가 속성에 속하는지 또는 내용에 속하는지 결정하는 매우 간단한 규칙이 있습니다. 그것은 데이터가 탐색 가능한 하위 구조를 가지고 있는지 여부입니다.

예를 들어, 비표시 텍스트는 항상 속성에 속합니다.항상.

목록은 하위 구조 또는 내용에 속합니다.시간이 지남에 따라 내장된 구조화된 하위 콘텐츠를 포함할 수 있는 텍스트가 콘텐츠에 속합니다. (내 경험으로는 데이터 저장 또는 교환을 위해 XML을 사용할 때 마크업이 포함된 텍스트가 상대적으로 적습니다.)

이렇게 작성된 XML 스키마는 간결합니다.

다음과 같은 경우를 볼 때마다<car><make>Ford</make><color>Red</color></car>, 저는 "저자가 메이크 요소 안에 하위 요소가 있을 거라고 생각했나요?"라고 생각합니다.<car make="Ford" color="Red" />훨씬 더 가독성이 높으며, 빈 공간을 어떻게 처리할지에 대해서는 의문의 여지가 없습니다.

공백 처리 규칙만 고려하면 XML 설계자의 명확한 의도가 있었다고 생각합니다.

XML 요소의 명확하고 모호하지 않은 정의는 요소의 시작 태그부터 요소의 끝 태그까지 모든 것입니다.

아래 예제는 텍스트가 있는 요소와 자식 요소입니다.요소의 이름은 This_Is_An_Element 입니다.내용은 여닫기 태그와 속성, 자식 요소 등 그 사이에 있는 모든 것들입니다.그리고 sub_element도 요소이지만 태그 외에는 내용이 없습니다.

<This_Is_An_Element>and this is clear text <sub_element/> etc. </This_Is_An_Element>

그리고, 속성은 요소의 멤버입니다.여기서 This_Is_An_Element에는 WithAnAttribute라는 속성이 있습니다.그리고 그 속성의 값은, 속성의 값입니다.이 특성은 This_Is_An_Element 요소의 일부입니다.

<This_Is_An_Element WithAnAttribute="Attribute's Value">and this is clear text <sub_element> etc. </This_Is_An_Element>

나는 페너에 동의합니다.가능하다면 속성에서 멀리 떨어지세요.요소는 진화 친화적이며 웹 서비스 툴킷 간의 상호 운용성이 뛰어납니다.이러한 도구 키트는 속성을 사용하여 요청/응답 메시지를 직렬화하는 것을 결코 찾을 수 없습니다.또한 메시지는 웹 서비스 툴킷을 위한 데이터(메타데이터가 아닌)이기 때문에 이는 타당합니다.

속성은 시간이 지나면 쉽게 관리가 어려워집니다. 저는 항상 개인적으로 멀리합니다.요소는 구문 분석기와 사용자 모두가 훨씬 더 명확하고 읽을 수 있습니다.

이 파일을 사용한 것은 자산 URL의 파일 확장자를 정의하는 것뿐이었습니다.

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

속성을 100% 확장할 필요가 없다는 것을 알고 있다면 사용할 수 있을 것입니다. 하지만 몇 번이나 알고 계십니까?

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

언급URL : https://stackoverflow.com/questions/33746/xml-attribute-vs-xml-element

'programing' 카테고리의 다른 글

curl 명령을 JavaScript로 변환 (0)	2023.09.17
모든 하위 요소에 대한 클래스 제거 (0)	2023.09.17
$http 호출의 전체 호출 스택 추적 가져오기 (0)	2023.09.17
CSS @media 규칙을 인라인으로 넣을 수 있습니까? (0)	2023.09.17
파워셸에서 오디오 레벨을 변경하시겠습니까? (0)	2023.09.17

현재글XML 특성 대 XML 요소

각종 프로그래밍 정보를 다루는 블로그입니다.

iphone, JSON, Wordpress, oracle, typescript, CSS, AngularJS, spring-boot, Python, mongodb, sql-server, C, git, ASP.NET, AJAX, JQuery, mysql, Excel, reactjs, mariaDB,

Today :
Yesterday :

일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

testman

XML 특성 대 XML 요소

XML 특성 대 XML 요소

XML 요소 대 XML 특성

'programing' 카테고리의 다른 글

'programing'의 다른글

티스토리툴바

XML 특성 대 XML 요소

XML 특성 대 XML 요소

XML 요소 대 XML 특성

'programing' 카테고리의 다른 글

'programing'의 다른글

관련글

티스토리툴바