XML 디자인 - 방법?

우리는 현재 RESTful 응용 프로그램의 디자인 작업을하고 있습니다. 우리는 XML을 기본 표현으로 결정했습니다. XML로 응용 프로그램 데이터를 설계/모델링하는 것과 관련하여 다음 질문을합니다.XML 디자인 - 방법?

XML의 데이터 모델링에 대한 접근 방법은 무엇입니까? 처음부터 시작하여 표준 XML 스키마의 사용을 평가하거나 그 반대로 평가하는 것이 좋습니다.
모든 표준 XML 스키마에 대한 정보는 어디에서 찾을 수 있습니까?
내가 처음부터 네임 스페이스를 생각해야할까요, 아니면 나중에 연기 할 수있는 것이 있습니까?
마지막으로 XML 스키마를 먼저 설계하거나 XML 문서로 시작한 다음 스키마를 정의하는 것이 좋습니까?

참고 : 이미 stackoverflow (What are best practices for designing XML schemas?)에서 관련된 질문을 살펴 봤지만 위의 질문을 해결하지 못하는 것 같습니다.

출처

2009-05-17 Suresh Kumar

이미 XML로 시작하려는 경우 ReST API를 계속 개발해야하는 이유는 무엇입니까? 처음부터 SOAP/WS (DL)를 사용하지 않는 이유는 무엇입니까? 나를 오해하지 마라. 필자는 ReST의 큰 지지자이지만 자신의 스키마로 XML을 사용하는 이점을 원한다면 API에 대한 전체 XML 툴체인을 탐구해야합니다. – Boldewyn

XML이 없거나 요구 사항을 모르는 경우 먼저 스키마를 디자인하기가 어려울 수 있습니다. XML을 처리해야하는 코드가 이미있는 경우 오브젝트 트리를 첫 번째 XML 트리의 예제로 사용하는 것이 가장 좋습니다. 그것들은 XML이 항상 단지 나무이고 당신의 객체가 아니라는 점을 제외하고는 다르지 않다.

다음으로 XML을 안정화하고 유스 케이스가 모델링되어야하는 요구 사항을 수집하십시오. 이 두 가지가 있으면 스키마를 수행하기에 완벽한 출발점이 있습니다. 이렇게하면 형식이 확고해질 것입니다.

표준 스키마를 찾는 것은 항상 좋은 생각이지만 거의 항상 좌절하는 것입니다. XML이 어떻게 보이는지 알 때까지 이것을 연기하십시오. 어쩌면 당신은 이미 당신의 포맷과 같은 표준화 된 것이 있다는 것을 인식 할 것입니다.

네임 스페이스에주의해야합니다. 이것은 당신이 너무 많은 실수를 할 수 있기 때문에 XML에서 더 무거운 가중치 주제입니다. 필요하다고 확신하지 않으면 건너 뛰십시오. 그것이 나머지 세계가하는 일입니다. 자신이 필요할 것이라고 생각하면 처음부터 사용하십시오. 네임 스페이스를 인식하지 못하는 코드와 네임 스페이스를 인식하는 코드를 혼용하는 것은 쉽지 않습니다.

출처

2009-05-17 12:24:03

나는 네임 스페이스를 빠뜨리는 것에 대해 강력하게 동의하지 않는다. 이것은 당신이 관심을 갖지는 않지만 라이브러리 (또는 고객이나 미래의 메인테이너 또는 통합 엔지니어)의 일부 사용자가 원할 수도있는, 더 큰 문서 다른 형식으로 작성하거나 * 귀하의 * 문서 내에 다른 종류의 정보를 포함 시키거나 귀하의 문서 형식에 대해 알지 못하는 타사 도구가 옳은 일을 할 것으로 기대하십시오. 따라서 네임 스페이스를 사용하는 것이 futureproofing을위한 더 안전한 선택입니다. –

글쎄 그것은 또 다른 "개인적인 결정"일뿐입니다. 당신은 프레임 워크, 타사 소프트웨어에 대해 이야기하고 있습니다. 나는 확률이 꽤 높다고 생각하지 않는다. 나머지 세계는 간단한 문제가 있습니다. 그렇습니다. 네임 스페이스가 올바른 방법이기는하지만 네가 할 일이 너무 복잡 할 수도 있습니다. 따라서 유스 케이스가 무시하는 네임 스페이스에 신경 쓰지 않는다면, –

네임 스페이스를 남겨 두는 것은 중요하지 않은 애플리케이션에서 잘 작동합니다. 원인과 결과, 또는 그 반대? –

추상 클래스, 열거 형 등과 같이 XML 스키마로 많은 작업을 수행 할 수 있습니다. XML Schema Part 0: Primer Second Edition을 참조하십시오. 상호 운용성에 관심이 있다면 try to stay away from certain data types.
List of XML markup languages에는 몇 가지 알려진 스키마가 나와 있습니다. POX on REST 서비스의 경우 자신이 직접 만들 것이라고 생각합니다.
고유성이 보장되는 한 실제 이름 자체는 별 문제가되지 않습니다. 향후 버전 관리를 위해 날짜를 포함하십시오.
결과 XML 문서가 어떻게 보이는지에 대한 아이디어가 있어야한다고 생각합니다.

서비스 설계에 대해주의해야 할 점 중 하나는 클래스/객체 설계와 다르고 문서 교환이라는 점에서 더 많이 생각해야한다는 것입니다. 이것을 course-grained라고도합니다. OO 세계에서는 동료들 사이에서 일련의 메소드 호출을 교환 할 것이지만 SOA에서는 복잡한 정보를 피하고 문서에 필요한 정보를 대부분 채우려는 경향이 있습니다. 일종의 세금 양식을 작성하는 것과 같습니다.

출처

2009-05-17 12:23:21

귀하의 신청서를 먼저 디자인하고 교환해야하는 정보를 결정해야한다는 것에 동의합니다.

여러분이하고있는 것처럼, 여러분이 교환하고있는 정보 중 일부는 표준 스키마에서 찾을 수 있습니다. 교환하려는 정보를 이미 설명하고있는 고객이 사용하는 표준 스키마가 있음을 알 수 있습니다.

이러한 상황이 발생하지 않으면 "표준 스키마"를 잊어 버리십시오. 무엇보다도, 나는 당신이 그들에 대한 포괄적 인 목록을 찾을 것이라고 생각하지 않는다. 너무 많다.

출처

2009-05-17 20:47:28

처음부터 네임 스페이스 디자인 방식을 생각하는 것이 좋습니다. 설계하려고하는 XML 파일이 개념적으로 관련되어 있다면 동질성의 네임 스페이스 디자인 접근 방식을 사용할 수 있습니다.

Heteregeneous 네임 스페이스 디자인 방식은 공유 및 재사용을 허용합니다. 이 기능은 도메인 별 파일을 시각적으로 식별하려는 경우에 사용할 수 있습니다.

이기종 디자인 방식이 권장됩니다. http://technologyandleadership.com/three-schema-design-approaches/을 참조하여이 설계 방식을 프로젝트에 구현하는 방법을 알려주십시오.

출처

2009-12-22 11:41:58 Aruna

XML 디자인 - 방법?

답변

관련 문제