XML에서 Elements(요소) 또는 Attribute를 사용해야 합니까?
저는 W3 학교에서 XML 속성에 대해 배우고 있습니다.
저자는 다음과 같이 언급합니다.(empassis mine)
XML 요소 대.특성
<person sex="female"> <firstname>Anna</firstname> <lastname>Smith</lastname> </person>
<person> <sex>female</sex> <firstname>Anna</firstname> <lastname>Smith</lastname> </person>첫번째 예에서 성별은 속성입니다.마지막으로 성관계는 하나의 요소입니다.두 예제 모두 동일한 정보를 제공합니다.
속성 사용 시기와 요소 사용 시기에 대한 규칙은 없습니다.속성들은 HTML에서 유용합니다. XML에서 제 조언은 속성들을 피하는 것입니다. 대신 요소를 사용합니다.
XML 특성을 피하시겠습니까?
속성을 사용할 때 발생하는 몇 가지 문제는 다음과 같습니다.
- 특성은 여러 값을 포함할 수 없습니다(elements는 포함할 수 있음).
- 특성에는 트리 구조를 포함할 수 없음(elements 캔)
- 속성을 쉽게 확장할 수 없음(향후 변경 시)
속성은 읽고 유지하기가 어렵습니다.데이터에 요소를 사용합니다.데이터와 관련이 없는 정보에는 속성을 사용합니다.
그렇다면 저자의 견해는 유명한 것일까요, 아니면 이것이 XML에서 가장 좋은 방법일까요?
XML의 속성을 피해야 합니까?
W3Schools는 다음과 같은 내용도 언급했습니다.
메타데이터의 XML 특성
때로는 요소에 ID 참조가 할당되기도 합니다.이 ID는 HTML의 ID 속성과 거의 동일한 방식으로 XML 요소를 식별하는 데 사용할 수 있습니다. 이 예는 다음을 보여줍니다.
<messages> <note id="501"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note> <note id="502"> <to>Jani</to> <from>Tove</from> <heading>Re: Reminder</heading> <body>I will not</body> </note> </messages>위 ID는 서로 다른 노트를 식별하기 위한 식별자일 뿐입니다.그것은 노트 자체의 일부가 아닙니다.
여기서 제가 말하고 싶은 것은 메타데이터(데이터에 관한 데이터)는 속성으로 저장되어야 하고, 데이터 자체는 요소로 저장되어야 한다는 것입니다.
속성 또는 요소의 사용은 일반적으로 모형화하려는 데이터에 따라 결정됩니다.
예를 들어 특정 개체가 데이터의 일부인 경우 요소로 만드는 것이 좋습니다.예를 들어 직원의 이름은 직원 데이터의 필수적인 부분입니다.
이제 데이터에 대한 메타데이터(데이터에 대한 추가 정보를 제공하는 것)를 전달하고 싶지만 실제로 데이터의 일부가 아니라면 속성으로 만드는 것이 좋습니다.예를 들어, 각 직원이 백엔드 처리에 필요한 GUID를 가지고 있다고 가정하면 속성으로 만드는 것이 더 좋습니다.(GUID는 xml을 보는 누군가에게 정말 유용한 정보를 전달하는 것이 아니라 다른 목적으로 필요할 수도 있습니다.)
어떤 것이 속성이나 요소가 되어야 한다고 말하는 그런 규칙은 없습니다.
어떤 비용을 치르더라도 속성을 피할 필요는 없습니다.요소보다 모델링하기가 더 쉬운 경우도 있습니다.이는 실제로 표현하려는 데이터에 따라 달라집니다.
OP 이후 5년 동안의 나의 0.02년은 정반대입니다.제가 설명해 드릴게요.
- 유사한 데이터를 그룹화할 때 요소와 해당 데이터의 속성을 사용합니다.
- 모든 일에 요소를 사용하지 마세요.
- 만약 데이터가 (1에서 많은) 반복된다면, 이는 아마도 한 요소일 것입니다.
- 데이터가 반복되지 않고 다른 데이터와 상관관계가 있을 때만 의미가 있다면 이는 속성입니다.
- 데이터에 다른 속성(즉, 이름)이 없으면 속성입니다.
- 좋아요 요소를 함께 그룹화하여 수집 구문 분석 지원(예: /xml/문자)
- 유사한 요소 이름을 다시 사용하여 파싱 데이터 지원
- 절대로 요소 이름에 숫자를 사용하여 위치를 표시하지 마십시오.(즉, 캐릭터1, 캐릭터2)이 방법을 사용하면 구문 분석이 매우 어렵습니다(단순히 /문자가 아닌 #6, 구문 분석 코드 /문자1, /문자2 등 참조).
다른 방법으로 고려:
- 먼저 모든 데이터를 속성으로 간주합니다.
- 속성을 요소로 논리적으로 그룹화합니다.데이터를 알고 있다면 속성을 요소로 변환할 필요가 거의 없습니다.요소(수집 또는 반복 데이터)가 필요할 때는 이미 알고 있을 것입니다.
- 요소를 논리적으로 함께 그룹화합니다.
- 확장해야 할 경우 위 프로세스의 논리 구조를 기반으로 새로운 요소/속성을 추가합니다.새로운 어린이 요소 모음을 추가해도 디자인이 깨지지 않고 시간이 지남에 따라 더 쉽게 읽을 수 있습니다.
예를 들어, 책과 주요 등장인물들의 단순한 모음집을 보면, 제목에 "아이들"이 없을 것이고, 그것은 단순한 요소입니다.모든 캐릭터는 이름과 나이가 있습니다.
<book title='Hitchhiker's Guide to the Galaxy' author='Douglas Adams'>
<character name='Zaphod Beeblebrox' age='100'/>
<character name='Arthur Dent' age='42'/>
<character name='Ford Prefect' age='182'/>
</book>
<book title='On the Road' author='Jack Kerouac'>
<character name='Dean Moriarty' age='30'/>
<character name='Old Bull Lee' age='42'/>
<character name='Sal Paradise' age='42'/>
</book>
한 권의 책에 여러 명의 저자가 있을 수 있다고 주장할 수 있습니다.새 작성자 요소를 추가하여 확장하십시오(선택적으로 원래 @author 제거).물론, 원래 구조를 깨셨지만 실제로는 꽤 드물고 작업하기도 쉽습니다.단일 작성자가 어떻게든 변경되어야 한다고 가정한 원본 XML의 모든 소비자('책' 테이블의 열에서 작성자를 '작성자' 테이블로 이동하기 위해 DB를 변경할 가능성이 높습니다.
<book title='Hitchhiker's Guide to the Galaxy'>
<author name='Douglas Adams'/>
<author name='Some Other Guy'/>
<character name='Zaphod Beeblebrox' age='100'/>
<character name='Arthur Dent' age='42'>
<character name='Ford Prefect' age='182'/>
</book>
가장 중요한 것은 속성에 항목을 넣는 것이 XML의 세부 사항을 덜 상세하게 만든다는 것입니다.
비교하다
<person name="John" age="23" sex="m"/>
그에 반대하여
<person>
<name>
John
</name>
<age>
<years>
23
</years>
</age>
<sex>
m
</sex>
</person>
네, 그건 좀 편파적이고 과장된 것이지만, 당신은 요점을 이해합니다.
저는 구글을 이용해 정확한 질문을 검색해 보았습니다.먼저 XML 설계의 원칙 - 요소 대 속성의 사용 시기라는 기사를 보았습니다.하지만 그런 간단한 질문을 하기에는 너무 길게 느껴졌습니다.어쨌든 저는 이 주제에 대한 답을 모두 읽어보았지만 만족스러운 요약을 찾지 못했습니다.그래서 저는 뒤의 기사로 돌아갔습니다.요약 내용은 다음과 같습니다.
요소를 사용할 때와 정보의 비트를 표시할 때 속성을 사용할 때는 언제입니까?
- 해당 정보 자체가 요소로 표시될 수 있는 경우 요소에 입력합니다.
- 정보가 특성 양식에 적합하지만 동일한 요소에서 동일한 이름의 여러 특성으로 귀결될 수 있는 경우 대신 하위 요소를 사용합니다.
- 정보가 ID, IDREF, ENTITY와 같은 표준 DTD 유사 속성 유형이어야 하는 경우 속성을 사용합니다.
- 공백 정보를 정규화하지 않아야 할 경우 요소를 사용합니다. (XML 프로세서는 속성 값의 원시 텍스트를 변경할 수 있는 방식으로 속성을 정규화합니다.)
핵심내용원칙
해당 정보가 XML에서 표현되거나 전달되는 중요한 자료의 일부라고 생각하는 경우 요소에 입력합니다.정보가 주변적이거나 주 통신에 부수적이거나 애플리케이션이 주 통신을 처리하는 데 도움이 되는 순수한 목적이라고 생각하는 경우 속성을 사용합니다.
구조화 정보의 원리
정보가 구조화된 형태로 표현되는 경우, 특히 구조를 확장할 수 있는 경우 요소를 사용합니다.정보가 원자 토큰으로 표현되면 속성을 사용합니다.
가독성의 원칙
정보를 사람이 읽고 이해하려는 경우 요소를 사용합니다.기계가 정보를 가장 쉽게 이해하고 소화하는 경우 속성을 사용합니다.
요소/속성 결합의 원리
요소의 값을 다른 특성으로 수정해야 하는 경우 요소를 사용합니다.[...] 한 속성이 다른 속성을 수정하도록 하는 것은 거의 항상 끔찍한 생각입니다.
기사의 중요한 부분을 간략하게 요약한 것입니다.모든 경우에 대한 예시와 전체 설명을 보고 싶다면 원본 기사를 참조하십시오.
특성 모형 매핑.요소의 속성 집합은 값이 텍스트 또는 직렬화 가능한 값 유형인 이름/값 맵에 직접 동형화됩니다.를 들어, C어, C#Dictionary<string, string>를 XML 를 XML고,다로 나타낼 수도 있습니다.
이것은 요소의 경우에는 절대로 해당되지 않습니다.이름/값 맵을 요소 집합으로 항상 변환할 수 있지만, 그 반대의 경우는 그렇지 않습니다. 예를 들어 다음과 같습니다.
<map>
<key1>value</key1>
<key1>another value</key1>
<key2>a third value</key2>
</map>
와 key1, 는 .key1에 나타남key2.
이와 같은 형식으로 정보를 업데이트하기 위해 사용되는 DOM 코드를 살펴보면 이에 대한 의미가 더욱 명확해집니다.예를 들어 다음과 같이 쓰는 것은 사소한 일입니다.
foreach (string key in map.Keys)
{
mapElement.SetAttribute(key, map[key]);
}
그 코드는 간결하고 모호하지 않습니다.이와 대조하여 다음과 같이 말합니다.
foreach (string key in map.Keys)
{
keyElement = mapElement.SelectSingleNode(key);
if (keyElement == null)
{
keyElement = mapElement.OwnerDocument.CreateElement(key);
mapElement.AppendChild(keyElement);
}
keyElement.InnerText = value;
}
속성에 CDATA를 넣을 수 없습니다.제 경험으로는 조만간 작은 따옴표, 큰 따옴표, XML 문서 전체를 "구성원"에 넣고 싶을 것이고, 속성이라면 요소가 아닌 속성을 사용한 사용자를 욕하게 될 것입니다.
참고: XML에 대한 저의 경험은 주로 다른 사람들의 것을 정리하는 것이었습니다.이 사람들은 "XML은 폭력과 같다"는 오래된 격언을 따르는 듯 했습니다.사용해도 문제가 해결되지 않았다면 충분히 사용하지 못한 것입니다."
이 모든 것은 XML이 무엇에 쓰이느냐에 달려 있습니다.웹 서비스와 같이 대부분 소프트웨어와 기계 간의 상호 운용일 때 일관성을 위해서만 모든 요소를 통합하는 것이 더 쉽습니다(또한 WCF와 같은 일부 프레임워크에서는 이러한 방식을 선호합니다).사람이 사용하는 것을 목표로 한다면(즉, 주로 사람이 만들고 또는 읽는 것), 속성을 적절히 사용하면 가독성이 상당히 향상될 수 있습니다. XHTML은 XSLT 및 XML Schema의 합리적인 예입니다.
이것은 속성이 데이터에 대한 데이터인 경우의 예입니다.
데이터베이스는 ID 속성에 따라 이름이 지정됩니다.
데이터베이스의 "유형" 속성은 데이터베이스 태그 내부에서 찾을 것으로 예상되는 것을 나타냅니다.
<databases>
<database id='human_resources' type='mysql'>
<host>localhost</host>
<user>usrhr</user>
<pass>jobby</pass>
<name>consol_hr</name>
</database>
<database id='products' type='my_bespoke'>
<filename>/home/anthony/products.adb</filename>
</database>
</databases>
작성자의 지적이 정확합니다(속성에 값 목록이 포함될 수 있다는 점 제외).문제는 당신이 그의 논점에 신경을 쓰느냐 안 쓰느냐 입니다.
당신 마음대로 하세요.
저는 보통 속성이 메타데이터, 즉 데이터에 대한 데이터라는 것에 근거하여 작업합니다.제가 피하는 한 가지는 속성에 목록을 넣는 것입니다. 예를 들어요.
attribute="1 2 3 7 20"
그렇지 않으면 각 요소를 추출할 추가 수준의 구문 분석이 있습니다.XML이 목록의 구조와 도구를 제공하는 경우, 다른 사용자가 직접 입력해야 하는 이유는 무엇입니까?
속성을 선호하여 코딩하는 시나리오 중 하나는 SAX 파서를 통한 처리 속도입니다.SAX 파서를 사용하면 요소 이름과 속성 목록이 포함된 요소 호출이 반환됩니다.대신 여러 요소를 사용했다면 여러 개의 콜백(각 요소마다 하나씩)을 받을 수 있습니다.이것이 얼마나 많은 부담이 되고 있다고 생각하는지는 물론 논쟁의 여지가 있지만, 아마도 고려할 가치가 있을 것입니다.
그런 쓰레기 때문에 w3 학교는 피해야 합니다.그들이 자바스크립트에 대해 가지고 있는 끔찍한 것들보다 더 나쁜 것입니다.
일반적으로, 최종 사용자가 소비할 것으로 예상되는 데이터(인간 판독이든, 처리를 위해 정보를 수신하는 기계이든)가 요소 내에 가장 잘 포함되어 있다고 제안합니다.메타데이터(예: 컨텐츠와 관련된 ID이지만 최종 사용자에게 표시하기 위한 것이 아니라 내부 용도로만 사용할 수 있는 ID)는 속성에 있어야 합니다.
XML 형식을 결정할 때 주의해야 할 또 다른 사항은 다음과 같습니다.제가 기억하는 바로는 "id" 속성의 값이 모두 숫자가 아니라 XML의 이름 규칙을 충족해야 합니다. 그리고 물론 값은 고유해야 합니다.이러한 요구 사항을 충족하지 못하는 파일을 처리해야 하는 프로젝트가 있습니다(다른 측면에서는 깨끗한 XML이지만). 이로 인해 파일 처리가 더욱 복잡해졌습니다.
당신은 아마도 의미론적인 방법으로 그 문제를 볼 수 있을 것입니다.
데이터가 요소와 더 밀접하게 연결되어 있으면 속성이 됩니다.
즉, 요소의 ID를 요소의 속성으로 지정합니다.
그러나 문서 속성을 구문 분석하는 동안 요소보다 더 많은 두통이 발생할 수 있는 것은 사실입니다.
모든 것은 당신과 당신의 스키마를 어떻게 설계하느냐에 달려있습니다.
언급URL : https://stackoverflow.com/questions/1096797/should-i-use-elements-or-attributes-in-xml
'programing' 카테고리의 다른 글
| 서명되지 않은 int에 음수 값을 할당하면 어떻게 됩니까? (0) | 2023.09.27 |
|---|---|
| 새 Spring 세션을 추가할 때 cookie-value 오류 발생 (0) | 2023.09.27 |
| Python 문자열에서 알파벳이 아닌 문자를 모두 제거합니다. (0) | 2023.09.27 |
| Chrome에서 Ajax 동기화 요청 실패 (0) | 2023.09.27 |
| 다중 삽입 쿼리를 준비할 때 오류가 발생했습니다. (0) | 2023.09.27 |