XML 모범 사례 : 확장 성 계획

Question

현재 XML 형식을 만드는 중입니다. 나는 이것이 어디로 가고 싶은지에 대한 큰 아이디어를 가지고 있지만 처음에는 작게 시작하여 확장 성을 허용하고자합니다. XML 애트리뷰트, XML 애트리뷰트, 사용할 때, 두 가지의 장단점에 대한 주제를 많이 읽었습니다. 일반적인 컨센서스 (here 및 here 참조)는 가능한 경우 XML 요소를 사용하는 것으로 보입니다. 당신은 절대적으로 데이터 조각이 원자 적이며 결코 확장 될 필요가 없거나 정말로 요소를 다루는 방법에 대한 메타 데이터라는 것을 확신합니다.

여기 내 질문이 있습니다. 이 지침을 따르고 이와 같은 기본 XML 문서를 작성한다고 가정 해 보겠습니다.

<person> 
    <name>John Doe</name> 
</person> 

나는 최선의 방법이라고 생각했던 것을 따라했습니다. 이것은 현재 작동하는 가장 기본적인 형식이며 나중에 확장하려는 경우에 대비하여 데이터를 요소에 배치합니다. 이제 내가이 형식을 잠시 사용하고 있다고 말하고 그것을 확장하고 싶습니다. name 요소의 innertext에 전체 이름을 기대하는 기존 프로세스를 중단하지 않고 어떻게해야합니까?

이렇게 확장하면. 지금은 '이름'의 innerText와는 "존 DoeJohnDoeJohn 미상"가 될 것입니다 때문에

<person> 
    <name>John Doe 
     <firstname>John</firstname> 
     <lastname>Doe</lastname> 
     <alias>John Doe</alias> 
    </name> 
</person> 

그것은 과정을 기존의 휴식 것입니다. 나는 이것을 처리 할 방법이 있다는 것을 알고 있지만, 핵심은 innertext가 성을 포함 할 것으로 기대하는 기존의 것들을 깨뜨리지 않는 것이다.

쉽게 확장 할 수있는 유일한 방법은 'name'의 새 값 특성을 만드는 것입니다. 그러나 추가 복잡성을 원한다면 어떨까요? 여러 '별칭'값과 같습니다. 속성으로는 불가능합니다.

<person> 
    <name firstname="John" lastname="Doe" alias="John Doe">John Doe</name> 
</person> 

실제로 기존 프로세스를 손상시키지 않고이를 확장하는 유일한 방법은 새 요소 이름을 선택하는 것입니다.

<person> 
    <name>John Doe</name> 
    <extendedname> 
     <firstname>John</firstname> 
     <lastname>Doe</lastname> 
     <alias>John Doe</alias> 
     <alias>Jon Doe</alias> 
    </extendedname> 
</person> 

그래서이 일을하고 내 문제를 해결하지만 난 나 자신을 부탁 해요 것 "정확히 속성 대신 요소로 '이름'을위한 중요한 이유는 무엇입니까?" 최종적으로는 'name'이 'person'의 속성이거나 innertext가있는 자식 요소라면 결국에는 새로운 요소 이름을 사용해야하기 때문에 결국에는 마음에 들지 않는 것 같습니다.

이와 같은 하이브리드 방식이 가장 유연하고 최대한의 확장 성을 제공하지만 실제로이 작업을 수행하는 사람의 예는 찾을 수 없습니다. 당신이

<person> 
    <name value="John Doe" />> 
</person> 

...이 시작되면 그것은 쉽게 기존의 프로세스를 파괴하지 않고이로 변신 여전히 더욱 연장을 허용 할 수있다. 지도 사용 요소가 될 가능한 및 태그 내에서 '값'속성의 어떤 종류의 내부 값을 넣어야처럼

<person> 
    <name value="John Doe" /> 
     <firstname value="John" /> 
     <lastname value="Doe" /> 
     <alias value="John Doe" /> 
     <alias value="Jon Doe" /> 
    </name> 
</person> 

그것은 일종의 날 것으로 보인다. 그리고 항상 상식이 적용되어야하며 메시지, 메모 또는 메모 필드와 같이 적절한 경우 innertext를 사용해야합니다.

첫 번째 예에서 중요한 디자인 요소를 더 잘 이해하지 못했습니까? 역 호환성을 유지하면서 XML 스키마를 확장해야하는 경험이있는 사람이 있습니까? 여기에서 같은 문제 또는 해결책을 찾아야합니까? 모든 지침이나 전문가의 조언을 부탁드립니다.

Answer 1

당신이 이전 릴리스 '컨테이너 요소를 인식하도록 파서를 구축한다고 가정하면, 당신은이 작업을 수행 할 수 있습니다 : 당신은 모든 접두사를 좋아하지 않는 경우

분명히

<doc xmlns:v1="http://example.com/yourformat/1.0" 
    xmlns:v2="http://example.com/yourformat/2.0"> 
    <v1:person> 
    <v1:name>John Doe</v1:name> 
    <v2:name> 
     <v2:firstname>John</v2:firstname> 
     <v2:lastname>Doe</v2:lastname> 
     <v2:alias>John Doe</v2:alias> 
     <v2:alias>Jon Doe</v2:alias> 
    </v2:name> 
    </v1:person> 
</doc> 

이 v2 기본 xmlns을합니다.

---

이 방법은 v2 내용이 추가도 함께 문서는 여전히 v1 파서 완벽하게 유효합니다.