W3C XML Schema는 강력한 데이터 입력 및 정의 기능 덕분에 수많은 비즈니스 애플리케이션의 핵심이 되었다. 그러나 데이터 모델이 항상 정적인 것은 아니다. 스키마는 시간의 경과에 따라 새로운 정보와 요소 유형을 수용하기 위해 확장성을 허용할 방법이 종종 필요하다. 여러 접근 방식에서 필요에 따라 새 요소를 포함하도록 스키마를 확장할 수 있다. 이 기사에서 설명하는 여섯 가지 전략에서는 단일 네임스페이스 스키마를 확장하기 위한 기술을 제시한다. 처리 중인 데이터를 확장하기 위해 여러 네임스페이스를 사용하는 방법을 설명하려면 그 주제만 다룬 기사를 써야 할 것이다.

주: 본 기사에서는 W3C XML Schema 버전 1.0에만 초점을 맞춘다. W3C XML Schema 작업 그룹에서는 버전 1.1을 거의 완성한 상태이지만, 아직 승인을 받지는 못했고 변경 작업이 필요할 수 있다. 여기서 제시하는 예제들은 모두 현재 스펙을 기초로 한 것이다.

일반 요소

코드 목록은 시간의 경과에 따라 변화하는 데이터의 좋은 예다. 코드 목록은 제품 디스크립터, 자주 사용되는 용어 및 국가 또는 구/군/시 목록과 같이 특정한 의미를 가진 고유 코드 값의 목록이다. 이런 값들은 시간의 경과에 따라 사용자가 추가하고 애플리케이션 창에서 선택 내용을 채울 때 사용할 수 있는 데이터베이스 행에 저장되는 경우가 많다.

목록 1에 있는 간단한 색상 코드 목록은 새로운 데이터 선택 사항이 나타날 때 스키마를 확장할 방법을 나타낸 것이다. 이것은 네 가지 가능한 요소가 들어 있는 요소 유형 color를 포함한 간단한 코드 목록을 정의하며, 네 가지 중 첫 세 가지 요소는 알려진 색상 이름으로 주어진다. 그룹의 마지막 요소를 때로는 일반 요소라고 하며, 이 요소는 name 속성에 어떤 값이든 삽입할 수 있도록 디자인되었으므로, 시간의 경과에 따라 필요할 때 목록에 색상을 새로 추가할 수 있다. 애플리케이션이 완료 및 배포된 지 여러 달이 지난 후 새로운 색상을 선택하려면, 새 색상(아마 자주색)을 지정하고 other 요소를 name="purple" 속성과 함께 사용할 수 있다. 유효성 검증이 된 경우, <other> 요소가 허용되고 스키마를 변경할 필요 없이 계속 작업할 수 있다.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="color">
    <xs:complexType>
      <xs:choice maxOccurs="unbounded">
        <xs:element name="red" type="xs:string"/>
        <xs:element name="blue" type="xs:string"/>
        <xs:element name="green" type="xs:string"/>
        <xs:element name="other">
          <xs:complexType>
            <xs:attribute name="name" type="xs:string"/>
          </xs:complexType>
        </xs:element>
      </xs:choice>
    </xs:complexType>
  </xs:element>
</xs:schema>

이 스키마와 관련하여 일반 요소 확장을 사용하는 유효한 데이터의 샘플은 목록 2에 있다.

<color xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xsi:noNamespaceSchemaLocation="color.xsd">
  <red/>
  <green/>
  <other name="purple">cc00cc</other><!-- Extension data -->
  <other name="orange">ee9944</other><!-- Extension data -->
</color>

여기서 알 수 있듯이, 스키마가 purple 또는 orange라는 이름을 가진 요소를 정의하지는 않지만, 이런 이름들은 사용하는 확장 기술 때문에 데이터 인스턴스에 포함되어 유효한 것으로 구문 분석되었다. 이 기술은 정적 목록이 존재하지만 지속적으로 새 항목이 추가되는 경우에 유효하다. 데이터 작성은 약간 더 복잡할 수 있지만, 스키마와 관련 애플리케이션을 유지 관리하는 작업이 대폭 간소화된다. 물론, 이 데이터는 요소 대신 속성에 있는 모든 색상 정보를 관리할 수 있다.

이 데이터를 처리하려면 일반적인 <other> 요소가 데이터 인스턴스에서 발생할 때 이를 특수한 방법으로 다루어야 한다. XQuery 또는 XSLT 스타일시트의 XPath 문에서 미리 정의된 요소 중 하나를 테스트하고 알려진 색상을 표시할 수도 있다. 어느 한 언어에 알려진 요소 이름 중 하나를 선택하여 그에 따라 처리하는 기능이 있거나, <other> 요소를 선택하고 name=에 대한 속성 값과 색상 값(여기서는 각 색상에 대한 CSS 스타일 값으로 표현됨)에 대한 요소 내용을 읽을 수 있다.

위로

모듈식 스키마 어셈블리

여러 가지 이유로 스키마를 모듈화할 수 있겠지만, 이 섹션에서는 모듈 방식을 이용한 스키마 확장에 초점을 맞춰 설명한다. 즉, 여러 스키마 모듈을 작성하여 이들을 기본 스키마에 포함시키는 것이 기본 스키마 확장의 한 형태이다. 목록 3의 예제에서는 스키마 생성 <xs:include>를 사용하여 스키마 모듈을 가져온다.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

 <!-- Reference to External Module containing USaddress definition --> 
 <xs:include schemaLocation="USaddress.xsd"/>
  
 <!-- Element containing USaddress element from included module --> 
 <xs:complexType name="contact">
  <xs:sequence>
   <xs:element name="Name" type="xs:string"/>
   <xs:element ref="USaddress"/>
  </xs:sequence>
 </xs:complexType>
</xs:schema>

목록 3의 코드는 목록 4에 포함된 스키마 모듈을 가져온다.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="USaddress">
 <xs:complexType>
  <xs:sequence>
   <xs:element name="street1" type="xs:string" minOccurs="0"/>
   <xs:element name="street2" type="xs:string" minOccurs="0"/>
   <xs:element name="city"    type="xs:string"/>
   <xs:element name="state"   type="xs:string"/>
   <xs:element name="zip"     type="xs:string" minOccurs="0"/>
  </xs:sequence>
 </xs:complexType>
</xs:element>
</xs:schema>

이렇게 결합한 결과 스키마를 통해 목록 5의 데이터 인스턴스가 유효성 검증에 성공할 수 있다.

<contact>
 <name>Dale Waldt</name>
 <USaddress>
  <city>New York</city>
  <state>NY</state>
 </USaddress>
</contact>

해결된 스키마에는 원래 스키마와 포함된 스키마 모두로부터의 모든 선언이 들어 있을 것이다. 목록 5의 예제에서는 네임스페이스를 하나만 사용하므로, 요소 및 속성 이름이 최종적으로 해결된 형식에서 고유해야 한다. 또한, 발생 규칙이 해결된 형식에서 일관되어야 한다.

모듈 추가는 스키마 확장의 한 가지 형태이지만, 다른 환경과 애플리케이션용으로 유연한 스키마를 작성하기 위해 동적으로 어셈블된 모듈 세트를 빌드할 수 있는 잠재성이 개발 및 유지 관리 노력을 최적화하기 위한 강력한 개념으로 작용한다. 개발자가 엔터프라이즈 전체를 통해 선택적으로 사용하도록 하기 위해 미리 정의된 일관된 선언 라이브러리를 작성할 수 있다. 그렇다 하더라도, 이름 지정 충돌과 다른 오류가 발생하지 않도록 하려면 각별한 주의가 필요하고, 특히 단일 네임스페이스에서 더욱 주의한다.

위로

추상 요소 및 대체 그룹

W3C XML Schema에서는 유형 정의에서 동등한 요소의 그룹으로 취급되는 같은 위치에서 일반적으로 나타나는 요소 유형의 클래스를 고려한다. 예를 들어, 사람, 구/군/시, 숙박 시설, 음식점 및 박물관을 포함한 인라인 요소로 텍스트에 나타나는 여러 유형의 이름 지정된 오브젝트(즉, 사람, 장소, 사물)가 있을 수 있다. 단락에 굵은체, 기울임꼴 및 기타 인라인 요소가 있을 가능성이 있으므로, <b>, <i> 및 <inline>으로 이름 지정된 하위 요소를 가진 혼합된 컨텐츠로 정의되는 텍스트 <p> 요소에 대해, 목록 6에 있는 것과 같이 컨텐츠 모델을 정의할 수 있다.

<!-- Paragraph Element Type Definition with Abstract Element -->
<xs:element name="p">
  <xs:complexType>
    <xs:choice maxOccurs="unbounded" mixed="true">
      <xs:element name="b" type="xs:string"/>
      <xs:element name="i" type="xs:string"/>
      <xs:element ref="inline"/>
    </xs:choice>
  </xs:complexType>
</xs:element>

<xs:element name="inline" type="xs:string"/>
 
<!-- Substitution Element Types -->
<xs:element name="person" type="xs:string" substitutionGroup="inline"/>
<xs:element name="hotel"  type="xs:string" substitutionGroup="inline"/>
<xs:element name="city"   type="xs:string" substitutionGroup="inline"/>
<xs:element name="url"    type="xs:string" substitutionGroup="inline"/>
<xs:element name="email"  type="xs:string" substitutionGroup="inline"/>
<xs:element name="phone"  type="xs:string" substitutionGroup="inline"/>

목록 6에서는 <inline> 요소가 <inline>에 대한 규칙을 따르는 요소 선언에 있는 속성인 substitutionGroup="inline"에서 참조된다. 이는 다른 요소의 이름을 가진 대체 그룹의 멤버인 모든 요소 그 요소가 허용되거나 추상 요소가 이런 목적으로 작용할 수 있는 곳이면 어디든 배치될 수 있다는 뜻이다. 이 예제에서는 대체 그룹 요소 유형인 <person>, <phone> 등이 <inline> 요소가 있는 곳이면 어디든(이 경우에는 단락의 텍스트에 있는 인라인) 허용된다. 목록 7의 데이터 인스턴스는 이 스키마와 대체 그룹 확장에서 유효하다. (추상 요소를 참조하는 대체 요소에서 이 기술을 사용할 수도 있다.)

<p>This is a <b>paragraph</b> with several inline elements. This sentence mentions
<city>Chicago</city>, <person>Mayor Daly</person> and 
<hotel>The Drake Hotel</hotel> which are named entities that have specific 
markup applied to them. </p>

또한, 영향을 받는 모든 요소들은 다른 유형 정의의 컨텍스트에서 로컬이 아니라 글로벌로 선언되어야 한다. 대체 그룹 요소는 maxOccurs="unbounded"로 반복 가능한 일부 그룹에 있기 때문에 이들 요소는 어떤 순서로든 나타날 수 있다.

시간이 경과함에 따라, 새로 사용할 때 인라인 요소를 추가해야 할지도 모른다. 이 예제를 확장 가능하게 하는 것은 스키마 개발자가 새 요소가 대체 그룹의 멤버임을 표시하는 새 요소 선언을 추가하기만 하면 된다는 사실이다. 물론, 대체 그룹 멤버인 요소 선언의 블록을 따로 저장되고 주 스키마에 포함되는 스키마 모듈에서 관리할 수 있다. 그렇게 하면 대체 그룹에 새 요소 선언을 추가하는 프로세스가 간소화되고, 코드 목록 관리 및 확장과 거의 같은 방식으로 애플리케이션 인터페이스에서 관리 및 생성될 수도 있다.

위로

기존 유형에 대한 확장

W3C XML Schema를 통해 기존 유형 정의를 확장하여 추가 하위 요소를 더함으로써, 데이터 모델의 구조에 추가 요소를 더할 수 있다. 요소 또는 속성의 유형에 확장을 적용할 수 있다. 목록 8에 예제 유형 정의가 표시되어 있으므로, 사람 이름 정보가 들어 있는 요소의 내용을 정의할 수 있다.

<xs:complexType name="nameType">
  <xs:sequence>
   <xs:element name="fname" type="xs:string"/>
   <xs:element name="lname" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

이 정의에서는 아래의 인스턴스를 유효한 것으로 구문 분석한다(nameType 유형을 사용하여 <name> 요소가 정의되는 것으로 가정).

<name><fname>Dale</fname><lname>Waldt</lname></name>

목록 9의 예제를 이용해 nameType이라는 복잡한 유형에 추가 하위 요소를 제공할 수 있다. 이 예제에서, extendedNameType으로 이름 지정된 새 complexType이 (위에 정의된) 기본 유형 nameType에 확장이 적용될 것임을 표시한다는 것을 알 수 있다. 확장된 후에는 기본 유형이 그 자체의 정의 외에도 새로 확장된 유형의 특성을 상속할 것이다. 이 경우에는 하위 요소 <gen>을 위에 정의된 nameType 요소(<fname> 및 <lname> 요소를 이미 하위 요소로 가지고 있음)에 추가하는 것이 목적이다.

<xs:complexType name="extendedNameType">
  <xs:extension base="nameType">
    <xs:sequence>
      <xs:element name="gen" type="xs:string"/>
    </xs:sequence>
  </xs:extension>
</xs:complexType>

<xs:element name="para" ref="extendedNameType"/>

목록 9에 정의된 <para> 요소는 기본 유형 nameType뿐 아니라, 확장 요소 <gen>의 모든 하위 요소를 포함하도록 정의된 extendedNameType을 사용한다. 이를 통해 다음 인스턴스가 오류 없이 유효성 검증을 수행할 수 있다.

<para><fname>Dale</fname><lname>Waldt</lname><gen>Jr.</gen></para>

유효성 검증 중에 실제로 어떤 일이 일어나고 있는지 더 정확히 이해할 수 있도록, 목록 10의 예제는 유효성 검증기에 의해 확장이 해결될 때 초래되는 결과를 나타낸 것이다(이것은 스키마가 처리될 때의 스키마 뷰이며, 때때로 PSVI(Post Schema Validation Infoset)라고 부름). 여기서 알 수 있듯이, 구문 분석에서는 원래 <xs:sequence> 요소에서 lname에 대한 마지막 요소 선언 직후 <gen> 요소에 대한 새 선언을 단순히 삽입하지 않았다. 그 대신, 원래 요소 바로 뒤에 새 <xs:sequence> 요소를 추가하여 시퀀스의 시퀀스라는 결과를 낳았고, 그 순서를 유지하기 위해 추가 <xs:sequence> 요소에서 그것을 캡슐화했다. 사실, 상대되는 컴포지터인 <xs:choice> 또는 <xs:all>이 아니라, 컴포지터 <xs:sequence>에만 확장이 적용될 수 있다. (실제로는 <xs:choice> 컴포지터를 확장할 수 있지만, <xs:sequence> 요소를 삽입하는 것으로 끝난다.)

<xs:complexType name="ExtendedNameType">
  <xs:sequence>
    <xs:sequence>
      <xs:element name="fname" type="xs:string"/>
      <xs:element name="lname" type="xs:string"/>
    </xs:sequence>
    <xs:sequence>
      <xs:element name="gen" type="xs:string"/>
    </xs:sequence>
  </xs:sequence>
</xs:complexType>

목록 10의 코드에서도 다음 인스턴스의 유효성 검증을 허용한다.

<name><fname>Dale</fname><lname>Waldt</lname><gen>Jr</gen></name>

목록 11에서와 같이, label=에 대한 속성을 추가하기 위해 ParaType 복합 유형 정의가 확장되는 상황에서 어떤 유형을 확장할 때 속성을 추가할 수도 있다.

<xs:complexType name="ParaType">
  <xs:simpleContent>
    <xs:extension base="xs:string">
      <xs:attribute name="label" type="xs:string"
            use="required"/>
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>

<xs:element name="para" type="ParaType"/>

목록 11의 확장 예제에서는 다음 텍스트 인스턴스를 올바로 유효성 검증할 수 있다.

<para label="abc">Paragraph string text.</para>

위로

기존 유형을 다시 정의

한 스키마에 정의된 유형은 다른 스키마 모듈에서 다시 사용하고 다시 정의할 수 있다. 스키마를 상속하지만 사용자 환경에서 더 원활하게 작동하도록 정의를 약간 수정하려는 경우 이 작동이 편리할 수 있다. 목록 12에서와 같이, yearType 단순 유형에 대한 simpleType을 정의하는 산업 표준 스키마가 주어져 있다고 가정하자.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <xsd:simpleType name="yearType">
    <xsd:restriction base="xsd:string"/>
  </xsd:simpleType>

  <xsd:element name="year" type="yearType"/>

</xsd:schema>

목록 12의 yearType은 <xs:string>으로 엄격히 정의되지만, 사용자의 로컬 환경에서 충분히 엄격하지 않을 수도 있다. 아마 다른 환경에서는 두 자리 또는 네 자리의 연도를 찾을 수도 있을 것이고, '09와 같이 아포스트로피가 포함되어 있을 수도 있다. 그러나 내부 환경에서는 연도를 최대한 분명하게 표시하기 위해 항상 연도를 네자릿수로 자동 설정하고 싶을지도 모른다. schemaLocation= 속성을 통해 원래 스키마를 호출하고 그것을 목록 13의 코드로 다시 정의하는 별개의 스키마 모듈을 생각해보자.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <xsd:redefine schemaLocation="prod1.xsd">
    <xsd:simpleType name="yearType">
      <xsd:restriction base="yearType">
        <xsd:length value="4"/>
      </xsd:restriction>
    </xsd:simpleType>
  </xsd:redefine>

  <xsd:element name="fullYear" type="yearType"/>

</xsd:schema>

yearType이 다시 정의되었으므로 여전히 같은 이름을 사용하는 것으로 설명되지만, <fullYear> 요소에 적용될 때는 fullYear에 항상 네자릿수가 포함되도록 해준다.

다시 정의하려면 이전 정의와 새 정의가 동일한 원래 유형을 기본 데이터 유형으로 가지고 있어야 한다. 목록 13의 예제에서는 xs:string으로 정의된다.

위로

와일드카드

W3C XML Schema에서는 다른 요소 또는 속성(선언됨 또는 선언 안 됨)에 대해서만 포함할 수 있는 요소 또는 와일드카드를 사용하여 몇몇 요소를 선언할 수 있다. 와일드카드 ANY 유형은 어떤 스키마에 대해 내용이 유효성 검증되거나 될 수 없는 플레이스홀더이다. 유효성 검증은 processContents 속성을 다음 레벨 중 하나로 설정함으로써 제어된다.

• Skip(건너뛰기): 내용을 유효성 검증하지 않는다.
• Lax(느슨함): 해당 선언을 찾을 수 있는 경우에만 유효성 검증을 수행한다.
• Strict(엄격함): 현재 스키마에 대한 유효성 검증을 수행한다.

요소 또는 속성에 대해서 각각 <xs:any> 또는 <xs:anyAttribute> 요소를 사용하여 와일드카드를 정의한다. 목록 14의 예제는 하위 요소 또는 속성이 선언되는 곳에 와일드카드가 있는 <HTMLExample>로 이름 지정된 요소를 나타낸 것이다. 달리 말해, 다른 어떤 요소든 올바른 형식의 마크업이 있는 경우에는 항상 <HTMLExample> 요소가 그런 요소를 포함할 수 있다. XHTML Schema를 추가하고 그에 대해 요소에서 구문 분석하도록 허용한 다음, processContent 레벨을 lax로 설정하여 유효한 HTML 마크업인지 검사할 수 있다. 그러나 이 예제가 와일드카드 요소 검사에 방해가 되지는 않으므로, skip으로 설정된 상태로 둔다.

<xs:element name="HTMLExample">
 <xs:complexType mixed="true">
  <xs:sequence>
   <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
   </xs:sequence>
   <xs:anyAttribute processContents="skip"/>
 </xs:complexType>
</xs:element>

특히, 목록 14의 예제는 시퀀스를 포함한 복잡한 유형을 포함하기 위한 요소 선언을 나타낸 것이다. 이 시퀀스에는 이 위치에 어떤 요소 마크업이든 나타날 수 있음을 표시하는 와일드카드 플레이스홀더인 <any> 요소가 들어 있다. 이 시퀀스에는 올바른 형식의 속성을 요소 마크업에 추가하도록 허용하는 <xs:anyAttribute> 선언도 들어 있다. 이 요소의 내용 처리를 건너뛰어야 하므로, 시작 태그와 종료 태그 사이에 있는 내용에 대해서는 스키마 유효성 검증이 수행되지 않는다. 따라서 전체 요소에는 임의의 요소 또는 속성 이름을 사용하는 올바른 형식의 마크업이라면 어떤 것이든 포함될 수 있다. 이런 식으로, 이 요소 내에 있는 다른 문서 모델의 내용을 추가할 수 있으므로, 요소가 특정 위치에 있더라도 문서 전체에서 요소의 유형 확장이 허용된다. 이 예제에서 목록 15의 데이터 인스턴스는 유효한 것으로 지정되어 있다.

<HTMLExample href="http://www.w3.org">
  <tr>
    <th align="left">Table Head</th>
  </tr>
</HTMLExample>

목록 15의 예제에서, 요소 유형 <HTMLExample>은 스키마에 대해 정상적으로 유효성 검증되지만, 그 요소의 내용, 테이블 행 및 테이블 헤드 HTML 요소는 건너뛴다.

유효성 검증이 필요할 것으로 예상하는 경우 와일드카드를 사용하거나 스키마를 찾을 수 있는 경우 느슨한 유효성 검증을 허용할 때는 주의를 기울이자. 유효성 검증을 수행할 대상이 되는 대체 스키마와 같은 자원을 프로세서에서 사용 가능하게 해야 한다. 네임스페이스는 올바로 관리되어야 한다. 또한, 선택적이거나 반복 가능한 요소와 함께 와일드카드를 사용하면 모호하고 확정적이지 않은 조건을 초래할 수 있다. processContents="skip"으로 와일드카드를 가장 간단한 방법으로 사용하면 이런 복잡도 문제를 대부분 피할 수 있을 것이다.

위로

결론

본 기사의 예제들에서 알 수 있듯이, W3C XML Schema 언어의 디자이너들은 확장성을 염두에 두고서 표준을 작성했다. 따라서 이 언어가 올바로 작동되도록 하려면 각각의 확장 유형에 대한 규칙을 준수하는 데 주의를 기울여야 한다. 비록 단일 네임스페이스에서만 작동하지만, 이런 강력한 기술을 이용하면 엄청난 유연성을 누릴 수 있으며, 특히 분산 환경과 다양한 유형의 환경에서 사용되는 스키마 작업 시 더욱 큰 효과를 볼 수 있다.

장래를 생각하여, W3C XML Schema 작업 그룹에서 만들고 있는 새로운 XML Schema 버전 1.1 표준에 유의하자. 이 표준에는 와일드카드와 기타 생성 방법에 몇 가지 흥미로운 변화가 도입되었고, 이런 변화로 인해 본 기사에서 소개한 예제도 영향을 받을 수 있다.

참고자료

교육

• Definitive XML Scheema(Prentice Hall, 2001년): W3C의 XML Schema에 관해 명확한 정보를 제공하는 Priscilla Walmsley의 저서를 살펴보자.
  
  
• W3Schools XML Schema Tutorial: XML Schema에 대한 W3C 튜토리얼을 구할 수 있다.
  
  
• W3C XML Schema Working Group: W3C XML Schema 작업 그룹에서 하는 일에 대해 알 수 있다.
  
  
• Design XML schemas for enterprise data(Bilal Siddiqui, developerWorks, 2006년 10월): XML 스키마 디자인에 관한 Bilal Siddiqui의 튜토리얼을 구할 수 있다.
  
  
• Compound XML document profiles for rich content, Part 1: Exploring extensibility alternatives using XML Schema(Steve Speicher와 Kevin E. Kelly, developerWorks, 2005년 9월): 코어 스펙 스키마에서 복합 XML Schema 프로파일을 빌드하는 방법을 알아보자.
  
  
• Real-world XML Schema(Paul Golick과 Richard Mader, developerWorks, 2002년 1월): XML 사용에 있어 널리 적용 가능한 17가지 실제 사례를 검토해보자.
  
  
• XML Schema 1.1: An introduction to XML Schema 1.1(Neil Delima, Sandy Gao, Michael Glavassevich, Khaled Noaman, developerWorks, 2008년 12월): 본 기사 시리즈에서 다룬 버전의 표준에서 도입되는 새로운 기능과 개선된 기능을 탐색해보자.
  
  
• developerWorks의 XML 영역: XML 영역에서 기술 향상에 도움이 되는 참고자료를 얻을 수 있다.
  
  
• IBM XML 인증: XML 및 관련 기술에 대한 IBM 인증 개발자가 되는 방법을 찾아볼 수 있다.
  
  
• XML 기술 자료: developerWorks XML 영역에서 다양한 기술 관련 기사와 팁, 튜토리얼, 표준 및 IBM Redbook을 볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트: 이들 세션에 참가하여 최신 기술에 대한 정보를 얻을 수 있다.
  
  
• developerWorks 팟캐스트: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
  
  

제품 및 기술 얻기

• IBM 제품 평가 버전: 이 버전을 다운로드하거나 IBM SOA Sandbox에서 온라인 평가판을 탐색하여 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구와 미들웨어 제품에서 실습을 해보자.
  
  

토론

• XML 영역 토론 포럼: 여러 XML 관련 토론에 참여해 볼 수 있다.
  
  
• developerWorks 포럼 & 블로그: 이러한 블로그를 읽어보고 참여할 수 있다.
  
  

필자소개

Dale Waldt는 25년여 동안 다양한 분야의 정부, 상업 및 비영리 조직을 위한 XML 애플리케이션, 컴포지션 및 게시 솔루션, 복잡한 웹 사이트의 디자인과 개발을 주도한 경험을 보유하고 있다. Dale은 자주 다양한 개발 팀과 함께 일하면서 프로세스 최적화, 스키마 디자인, 데이터 및 애플리케이션 디자인과 개발 업무 지휘, 소프트웨어 및 서비스 평가, XML, XSLT 및 관련 기술 분야의 개발자 교육 업무 등을 수행한다. 지난 10년 동안, Dale은 웹 및 컨텐츠 기술과 개방형 표준 채택에 주력하여 해당 분야의 컨설턴트, 강사 및 산업 분석가로 활동했다. Dale의 이메일 주소는 dale@axtiveminds.com이다.

아티클 순위

의견

위로

목차

• 일반 요소
• 모듈식 스키마 어셈블리
• 추상 요소 및 대체 그룹
• 기존 유형에 대한 확장
• 기존 유형을 다시 정의
• 와일드카드
• 결론
• 참고자료
• 필자소개
• 의견