지난 토픽에서, 우리는 스키마 상속에 관한 처리를 살펴봤습니다.
이번 회에서는, 실제로 그러한 스키마 상속에 대해서 XSDObjectGen.exe가 어떻게 처리하는 지를 보고, 무엇을 개선해야 하는지를 파악해 보도록 하겠습니다.
우선, 지난주에 살펴본 2개의 스키마를 아래에 실어보겠습니다.
======== 부모 스키마 : DataTypes.xsd =======
<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="DataTypes" targetNamespace="https://www.sysnet.pe.kr/DataTypes.xsd" elementFormDefault="qualified" xmlns="https://www.sysnet.pe.kr/DataTypes.xsd" xmlns:mstns="https://www.sysnet.pe.kr/DataTypes.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="TFSAddItemT">
<xs:attribute name="Name" type="xs:string" />
<xs:attribute name="Port" type="xs:int" />
<xs:attribute name="Protocol" type="ProtocolEnum" />
</xs:complexType>
<xs:simpleType name="ProtocolEnum">
<xs:restriction base="xs:short">
<xs:enumeration id="HTTP" value="80" />
<xs:enumeration id="HTTPS" value="8080" />
</xs:restriction>
</xs:simpleType>
<xs:element name="CollectionDef">
<xs:complexType>
<xs:sequence>
<xs:element name="TFSAddItemList" type="TFSAddItemT" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
======== 상속 스키마 : DerivedSchema.xsd =======
<?xml version="1.0" encoding="utf-8"?>
<xs:schema id="DerivedSchema" targetNamespace="https://www.sysnet.pe.kr/DerivedSchema.xsd" elementFormDefault="qualified" xmlns="https://www.sysnet.pe.kr/DerivedSchema.xsd"
xmlns:mstns="https://www.sysnet.pe.kr/DerivedSchema.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:dtypes="https://www.sysnet.pe.kr/DataTypes.xsd">
<xs:import id="dtypes" namespace="https://www.sysnet.pe.kr/DataTypes.xsd" schemaLocation="DataTypes.xsd">
</xs:import>
<xs:complexType name="DerivedLocation">
<xs:sequence>
<xs:element name="Location" type="dtypes:TFSAddItemT" />
</xs:sequence>
</xs:complexType>
<xs:complexType name="TFSAddExT">
<xs:complexContent>
<xs:extension base="dtypes:TFSAddItemT">
<xs:sequence />
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
일단, 현재 버전의 SmallTool 1,0,0,6에서 제공하는 "STXSDObjectGen" custom tool은 상속 스키마에 대한 소스 생성을 지원하지 않습니다. 따라서, VS.NET 2005 속성창에 Custom Tool을 지정해도 cs 파일은 생성되지 않습니다.
그러니, 일단 ^^ "STXSDObjectGen"는 접어두고. XSDObjectGen.exe를 통해서 어떻게 소스 생성을 할 수 있는지 보겠습니다.
SmallTool을 설치했으면, "시작" / "SmallTool" /
"ConsoleBat"을 실행시킵니다.
다음과 같이 XSDObjectGen.exe를 실행시킵니다.
C:\...\Data>XSDObjectGen.exe DerivedSchema.xsd /n:TestLib
아시는 것처럼, DerivedSchema.xsd는 import를 통해서 DataTypes.xsd를 참조하고 있습니다.
바로, 여기에서부터, XSDObjectGen.exe는 무리를 하기 시작합니다. ^^;
그냥, DerivedSchema.xsd 파일에 대한 DerviedSchema.cs 파일 하나만 생성해 주면 될 것을, 자신이 참조하고 있는 모든 Schema 파일을 포함시켜서 생성해 주려고 합니다. 실제로, 대부분의 프로젝트에서 외부 XSD를 참조하기 위해 URL을 지정해서 import 하는 경우는 거의 없습니다. 설령 URL을 지정한다고 해도 해당 URL에서 다운로드해서 현재의 솔루션에 추가시키면 그만이니까요. 자, 그럼 여기서 또 다른 고민이 시작됩니다. "XSD 스키마의 일관성"을 URL을 통해서 유지시키지 않으면 어떤 방법이 있을런지? 이 부분을 보완하기 위해서 저는 "소스 컨트롤 시스템"을 권장합니다. 즉, 스키마 전용의 프로젝트를 생성해서 소스 컨트롤 시스템에 넣고 관리를 하는 것이지요.
잠깐 이야기가 옆으로 새었는데, 다시 원점으로 돌아와서, XSDObjectGen.exe는 결국 참조된 DataTypes.xsd와 함께 DerivedSchema.xsd에 관계된 소스를 생성하기 위해 다음과 같이 각각에 해당하는 네임스페이스를 묻게 됩니다.
Imported namespaces were found. Please enter valid .NET namespace names for each namespace.
WARNING. Namespaces chosen must not conflict with types and element names from the schemas.
Xsd namespace = https://www.sysnet.pe.kr/DerivedSchema.xsd.
Please enter a CLR namespace name for this namespace: DerivedLib <=== 입력된 부분
Xsd namespace = https://www.sysnet.pe.kr/DataTypes.xsd.
Please enter a CLR namespace name for this namespace: DataTypesLib <=== 입력된 부분
Done.
Writing file DerivedLib.cs.
Writing file DataTypesLib.cs.
[문제점 1]
2번의 입력을 받아들이게 되는데요. 만약, 3개의 XSD가 엮어져 있다면 ^^ 3번 묻게 됩니다. 여간 귀찮은 일이 아닐 수 없는데요. 더군다나, 이 부분은 SmallTool의 "STXSDObjectGen"의 소스 자동 생성에도 걸림돌이 됩니다.
[문제점 2]
그리고, 이렇게 입력을 받아들인다는 점 이외에도 한 가지 더 문제가 있습니다.
즉, 위에서 네임스페이스를 받아들이게 되는데, 이때 같은 이름을 주면 파일은 나중의 XSD 내용을 포함하는 하나의 파일만 생성되게 됩니다. 2개의 XSD 코드 생성을 합친 것이 아닌, 맨 나중의 소스 생성 파일만 남게 된다는 것입니다.
[문제점 3]
또 한 가지, 문제점 2번 사항으로 인해 발생하는 것인데, 2개의 XSD 파일은 절대로 하나의 .NET Namespace 아래에 정의될 수 없습니다. 무조건 다른 네임스페이스를 가져야 합니다.
그럼, SmallTool 1,0,0,7에서는 위의 3가지 문제점을 해결할 수 있을까요? ^^
한번 접근해 볼 테니, 기다려 주십시오. ... 잘 되었으면 좋겠군요. ^^