다음을 통해 공유

InfoPath의 XML 스키마 사용

  • 아티클

Microsoft InfoPath 2010을 사용하여 만드는 양식 서식 파일은 XML 스키마(XSD)를 사용하여 InfoPath 양식에서 입력, 편집 및 출력되는 XML의 구조 및 데이터 유효성 검사를 수행합니다. InfoPath 양식 디자이너에서 만든 모든 양식 서식 파일에는 런타임에 유효성 검사에 사용되는 XSD 스키마 파일(.xsd)이 하나 이상 포함됩니다.

참고 사항참고 사항

이 항목에 포함된 정보는 InfoPath 2010 편집기에서 사용하도록 디자인된 양식 서식 파일에 적용됩니다. 브라우저 호환 양식 서식 파일은 XSD 스키마 요구 사항이 훨씬 엄격합니다. 자세한 내용은 MSDN에서 사용할 수 있는 브라우저 호환 양식 서식 파일의 XML 스키마에 대한 설명서를 참조하십시오.

외부에서 작성된 XML 스키마 사용

InfoPath 외부에서 작성된 XSD 스키마 파일을 로드하려면 다음 단계를 따르십시오.

외부 스키마를 기반으로 양식 서식 파일을 만들려면

  1. Backstage에서 새로 만들기를 클릭하고 고급 양식 서식 파일 아래의 XML 또는 스키마를 클릭한 다음 이 양식 디자인을 클릭합니다.

  2. 데이터 원본 마법사에서 사용할 XSD 스키마 파일을 지정한 후 다음을 클릭하고 마법사의 나머지 페이지를 완료합니다.

지원되지 않는 XSD 구문

다음 섹션에서는 InfoPath에서 런타임에 처리할 수 없는 XSD 구문에 대해 설명합니다. InfoPath 양식 디자이너에서 양식 서식 파일을 만들 때 이러한 구문은 사용하지 마십시오.

ENTITY 및 ENTITIES 형식

ENTITY 및 ENTITIES 형식의 경우 유효성 검사를 위해 DTD(문서 종류 정의)가 필요하지만 InfoPath에서는 DTD를 지원하지 않습니다. InfoPath에서는 이러한 스키마에 대해 양식 서식 파일을 디자인할 수 없으며 ENTITY 형식을 ENTITY가 파생되는 NCName 형식으로 변경할 것을 권장하는 오류 메시지가 표시됩니다.

참고 사항참고 사항

디자인 모드가 아닌 상태에서 수동으로 InfoPath 양식 서식 파일을 작성할 때 ENTITY 및 ENTITIES 형식이 포함된 XSD를 사용하는 경우 Template.xml 파일에 이러한 형식에 필요한 DTD가 있으면 런타임에 해당 양식 서식 파일이 작동할 수 있습니다.

필수 xsd:any 요소

xsd:any 와일드카드 요소, 즉 minOccurs 특성 값이 0보다 큰 xsd:any 요소("필수 any")가 있으면 InfoPath에서 이 스키마 조각에 대한 유효한 인스턴스를 결정적으로 만들 수 없습니다. InfoPath에서는 이 스키마 조각을 사용하는 양식을 생성할 때 유효한 인스턴스를 만들 수 있어야 합니다. 데이터 원본 마법사를 실행할 때 필수 xsd:any 요소가 있는 스키마의 경우 필수 xsd:any 요소 대신 사용할 스키마 요소를 선택해야 합니다.

추상 복합 형식 요소

InfoPath 디자인 모드에서는 추상 복합 형식을 사용하는 스키마에 대한 양식 서식 파일 디자인을 지원합니다. 예를 들어 shippingAddress라는 요소에 USAddress 및 CanadianAddress라는 두 가지 파생 요소가 있는 address라는 추상 복합 형식이 있는 경우 InfoPath에서는 모든 shippingAddress 인스턴스를 USAddress 형식의 shippingAddress와 CanadianAddress 형식의 shippingAddress 중 하나로 간주합니다. 이 예에서 제공된 스키마에 address에서 파생되는 형식이 포함되지 않는 경우에는 InfoPath에서 이러한 요구 사항을 충족하는 추가 스키마를 요청합니다.

기능 제한이 있는 XSD 구문

다음 섹션에서는 InfoPath 양식 디자이너에서 양식 서식 파일을 만드는 데 사용하는 경우 기능 제한이 있는 XSD 구문에 대해 설명합니다.

대체 그룹

대체 그룹의 모든 멤버는 필드 작업창에 나타납니다. InfoPath에서는 대체 가능성을 모든 대체 그룹의 선택 사항으로 나타냅니다(추상 요소가 아닌 경우 정의 요소 포함). 추상 요소에 대한 대체 그룹이 없는 경우에는 InfoPath에서 대체 그룹인 요소가 하나 이상 포함된 스키마를 제공하라는 메시지가 표시됩니다.

바인딩되지 않은 choice 요소

다음 스키마 조각은 바인딩되지 않은 choice 요소를 보여 줍니다.

<xsd:choice maxOccurs="unbounded"> 
    <xsd:element name="my_element_1"/> 
    <xsd:element name="my_element_2"/> 
</xsd:choice>

InfoPath에서는 반복 choice 요소가 필드 작업창에 반복 선택 사항으로 표시됩니다. XSD에서 반복 choice 요소에 의해 정의되는 다른 유형의 목록을 나타내는 데 사용할 수 있는 반복 선택 그룹 컨트롤이 있습니다.

반복 sequence

다음 스키마 조각은 반복 sequence를 보여 줍니다.

<xsd:sequence maxOccurs="unbounded"> 
    <xsd:element name="my_element_1"/> 
    <xsd:element name="my_element_2" minOccurs="0"/> 
</xsd:sequence>

반복 sequence에 필수 요소가 포함되는 한, InfoPath에서는 XSD를 수정하지 않고 로드하며 반복 섹션 컨트롤을 반복 sequence에 바인딩할 수 있습니다.

모델 그룹 선택

다음 스키마 조각은 여러 모델 그룹이 포함된 choice 요소를 보여 줍니다.

<xsd:choice> 
    <xsd:element name="my_element_1"/> 
    <xsd:sequence> 
        <xsd:element name="my_element_2"/> 
        <xsd:element name="my_element_3"/> 
    </xsd:sequence> 
</xsd:choice>

InfoPath 디자인 모드는 양식 디자이너에서 수정할 필요 없이 이러한 XSD 구문을 지원합니다. InfoPath는 스키마의 의미를 수정하지는 않지만 위 선택 구문을 필드 작업창의 상응하는 축소된 단일 선택으로 단순화합니다.

정규화된 이름이 동일한 선택적 형제 요소

다음 스키마는 정규화된 이름(QName)이 동일한 선택적 형제 요소를 보여 줍니다.

<xsd:sequence> 
    <xsd:element name="my_element_1" minOccurs="0"/> 
    <xsd:element name="my_element_2"/> 
            <xsd:element name="my_element_1"/> 
</xsd:sequence>

이러한 노드에 대한 XPath 식은 InfoPath 양식 디자이너에서 모든 잠재적 XML 인스턴스를 다뤄야 하므로 복잡할 수 있습니다. InfoPath에서는 올바른 XPath 바인딩을 만들기 어려운 스키마 부분을 노출하지 않습니다. 무시되는 스키마 부분에 관한 경고가 나타납니다.

InfoPath에서 특별한 의미가 있는 XSD 구문

다음 섹션에서는 디자인 모드에서 양식 서식 파일을 만드는 데 사용하는 경우 특별한 의미를 갖는 XSD 구문에 대해 설명합니다. 또한 스키마에서 해당 구문을 사용하여 특정 동작을 사용하도록 설정하는 방법을 설명합니다.

필드 작업창을 사용하여 새 요소 필드 및 그룹 추가

디자인 타임에 필드 작업창을 사용하여 요소에 새 요소 필드 및 그룹을 추가할 수 있도록 스키마를 구성할 수 있습니다. 이 작업을 수행하려면 ##any 와일드카드를 사용하여 네임스페이스 특성을 지정하는 선택적인 바인딩되지 않은 xsd:any 요소를 사용하여 스키마에서 요소를 선언합니다. 그러면 디자인 모드에서 필드 작업창을 사용하여 해당 요소에 새 요소 필드 및 그룹을 추가할 수 있습니다. 예를 들어 다음 요소에 새 콘텐츠를 추가할 수 있습니다.

<xsd:element name="open"> 
    <xsd:complexType> 
         <xsd:sequence> 
             <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="##any"processContents="lax"/> 
         </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

필드 작업창을 사용하여 새 특성 필드 추가

요소의 경우와 마찬가지로, ##any 와일드카드로 지정된 네임스페이스 특성이 있는 anyAttribute 요소를 사용하여 특성을 선언할 수 있습니다. 디자인 타임에 필드 작업창을 사용하여 해당 스키마 특성에 새 콘텐츠를 추가할 수 있습니다.

<xsd:element name="open"> 
    <xsd:complexType> 
        <xsd:anyAttribute namespace="##any" processContents="lax"/> 
    </xsd:complexType> 
</xsd:element>

데이터 원본에 XML 서명 저장

사용자가 런타임에 양식에 디지털 서명을 할 수 있도록 설정하려면 데이터 원본의 스키마에서 사용자가 양식에 서명할 때 만들어지는 XML 서명(디지털 서명) 정보를 저장하기 위한 singature 요소를 선언해야 합니다. 다음과 같이 와일드카드 문자를 사용하는 XML 서명 네임스페이스로 지정된 네임스페이스 특성이 포함된 xsd:any 요소를 사용하여 이 선언을 수행할 수 있습니다. "http://www.w3c.org/2000/09/xmldsig#"

<xsd:element name="signature"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:any namespace="http://www.w3c.org/2000/09/xmldsig#"  
             processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
        <xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

필드를 서식 있는 텍스트 상자 컨트롤에 바인딩

InfoPath의 서식 있는 텍스트 상자 컨트롤은 일반 XHTML을 생성합니다. 따라서 양식 인스턴스의 XML에서 모든 텍스트 및 XHTML 노드가 유효하도록 스키마에서 지정해야 합니다. 다음 XSD 구문을 사용하여 이러한 지정을 수행할 수 있습니다.

<xsd:element name="xhtml"> 
    <xsd:complexType mixed="true"> 
        <xsd:sequence> 
            <xsd:any minOccurs="0" maxOccurs="unbounded" namespace="http://www.w3.org/1999/xhtml" processContents="lax"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>
참고 사항참고 사항

InfoPath는 스키마 파일(.xsd)의 콘텐츠를 수정하지는 않지만 디자인을 위해 해당 콘텐츠 중 일부를 논리적으로 유추할 수 있습니다. 스키마 파일은 디자인 타임 및 런타임에 항상 양식 서식 파일 내에 그대로 유지됩니다.

일반적인 XSD 오류 디버그

외부에서 작성된 XSD 파일을 로드하여 InfoPath 양식 디자이너에서 양식 서식 파일을 만드는 경우 두 가지 유형의 오류 메시지, 즉 MSXML 오류 메시지 또는 InfoPath 오류 메시지 중 하나가 표시될 수 있습니다. MSXML 오류 메시지는 InfoPath 오류 메시지 대화 상자의 세부 정보 섹션에 표시되며 항상 오류가 발생한 스키마 파일의 이름 또는 경로에 대한 참조로 시작됩니다. InfoPath에서는 일부 유효한 XSD 스키마 구문이 지원되지 않습니다. 이에 대한 설명은 지원되지 않는 XSD 구문 섹션에 나와 있습니다. 다음 섹션에서는 InfoPath에서 스키마가 로드되지 않는 문제를 발생시킬 수 있는 몇 가지 일반적인 오류에 대해 설명합니다.

XSD 네임스페이스 선언

모든 W3C 표준과 마찬가지로 XML 스키마(XSD)도 권장 사항이 되기까지 긴 검토 과정을 거쳤습니다. 많은 수의 작업 초안이 있었고, 그 결과 이렇게 진화하는 표준을 기반으로 많은 XSD 파일이 작성되었습니다. 이 과정에서 Microsoft는 MSXML 3.0에 포함되었던 XDR(XML-Data Reduced)라는 전용 스키마 언어를 만들었습니다. MSXML 4.0 이상부터 Microsoft XML Core Services는 XSD의 전체 권장 사항을 지원합니다. 많은 스키마 작성 프로그램은 XSD가 전체 권장 사항이 될 때까지 기다리지 않았습니다. 이러한 프로그램의 이전 버전은 InfoPath에서 사용하는 MSXML 5.0 인프라에서 지원하지 않는 오래된 XSD 파일을 생성할 수 있습니다.

XSD 파일이 전체 XSD 권장 사항을 지원하도록 하려면 <schema> 태그에 다음 XML 네임스페이스 선언이 포함되어야 합니다.

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

모든 XML 네임스페이스 선언과 마찬가지로 XML 접두사(이 경우 'xsd')는 임의의 유효한 접두사 문자열일 수 있습니다. 실제로 사용되는 일반적인 접두사로는 'xsd', 'xs', ''(접두사 없음) 등이 있습니다. 이러한 네임스페이스 선언이 없는 경우에는 일반적으로 MSXML에서 루트가 올바르게 정의되어 있지 않다는 내용의 오류를 보고합니다.

스키마 가져오기 및 포함

XSD 스키마는 확장 가능하며 다른 스키마를 가져오거나 포함할 수 있습니다. 일반적으로 targetNamespace 특성에 지정된 스키마가 현재 스키마와 다른 경우에는 스키마를 가져와야 합니다. targetNamespace 특성에 지정된 스키마가 현재 스키마와 동일한 경우에는 해당 스키마를 포함해야 합니다.

스키마 가져오기 및 포함의 의미 체계는 다음과 같습니다.

<xsd:import namespace = "[anyURI]" schemaLocation = "[anyURI]"/> 
<xsd:include schemaLocation = "[anyURI]"/>

일부 변환기에서 발생하는 것처럼 schemaLocation 특성이 없는 경우 MSXML에서 파일을 찾을 수 없기 때문에 오류가 발생합니다. 이러한 오류 메시지가 표시되는 경우에는 양식 서식 파일의 사용자가 schemaLocation 특성에 지정된 리소스 또는 위치에 액세스할 수 있는지도 확인하십시오. schemaLocation 특성이 가동이 중지되었거나 존재하지 않는 서버나 디렉터리를 참조하는 경우 또는 사용자에게 액세스 권한이 없는 경우에는 확실히 오류가 발생합니다. 또한 가져온 스키마 및 포함된 스키마가 모두 유효한지 검사해야 합니다.

참고 사항참고 사항

schemaLocation 특성의 문제로 인해 발생하는 오류는 InfoPath에서 처음으로 스키마를 가져올 때, 즉 기존 스키마에 기반한 양식을 처음 디자인하기 시작할 때만 문제가 됩니다. 그 후에는 InfoPath에서 양식 서식 파일에 저장되는 캐시된 버전의 스키마 파일을 사용합니다.

스키마를 가져올 때 해당 스키마에서 targetNamespace 특성을 지정하지 않는 경우에는 빈 네임스페이스 특성을 사용할 수 있습니다. 일반적으로 가져올 때의 네임스페이스는 가져오는 스키마에 지정된 targetNamespace와 일치해야 합니다.

비결정적 스키마

InfoPath에서 사용하는 MSXML 5.0 인프라는 비결정적 스키마 오류를 안정적으로 감지하고 해당 오류를 알리는 메시지를 표시하지만 결과 오류 메시지에 스키마에서 해당 오류가 발생한 부분을 알려 주는 줄 번호는 나타나지 않습니다. 이 섹션에서는 XSD 스키마 파일이 결정적이어야 하는 이유와 XSD 스키마 파일이 비결정적일 경우 무엇을 의미하는지에 대해 설명합니다. 방지해야 할 몇 가지 일반적인 오류에 대해서도 설명합니다.

XSD 스키마는 XML 데이터 구조 및 형식 의미 체계의 유효성 검사를 위해 사용됩니다. 이 작업을 수행하려면 유효성 검사 시스템(이 경우 MSXML 5.0)에서 XML 노드를 XSD 선언에 매핑해야 합니다. 이러한 매핑을 수행하지 않으면 유효성 검사 시스템이 작업을 수행할 수 없습니다. 매핑을 보장할 수 있으면 해당 스키마는 결정적 스키마입니다. 이러한 매핑을 불가능하게 하는 XML 인스턴스가 하나라도 있으면 해당 스키마는 비결정적 스키마입니다.

다음 예의 스키마는 비결정적 스키마입니다.

<xsd:element name="file_Information"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element name="file_name"/> 
            <xsd:choice> 
                <xsd:element name="file_path"/> 
                <xsd:sequence> 
                    <xsd:element name="file_path" minOccurs="0"/> 
                    <xsd:element name="URI"/> 
                </xsd:sequence> 
            </xsd:choice> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

이 XSD 세그먼트가 비결정적인 이유를 설명하기 위해 이 스키마를 사용하여 다음 XML 조각의 유효성을 검사하는 경우를 가정해 보겠습니다.

<file_Information> 
    <file_name>my_Schema.xsd</file_name> 
    <file_path>c:\xsd</file_path> 
</file_Information>

이 XML 조각에서는 <file_path> 요소가 선택 선언 첫 번째 부분의 필수 노드인지, 아니면 선택 선언 두 번째 부분의 선택적 노드인지 명확하지 않습니다. 이러한 구분은 다음과 같은 이유로 중요합니다.

  1. XML 조각이 선택 선언의 첫 번째 부분에 대해 유효성이 검사되는 경우 XML이 스키마에 대해 유효합니다.

  2. XML 조각이 선택 선언의 두 번째 부분에 대해 유효성이 검사되는 경우에는 필수 <URI> 노드가 없기 때문에 스키마가 유효하지 않습니다.

일부 XSD 유효성 검사 시스템의 경우 유효한 경로가 있으므로 이 스키마에 대한 유효성 검사에서 잘못을 범할 수 있습니다. 그러나 MSXML은 보다 엄격한 검사를 통해 스키마가 비결정적이라는 내용의 오류 메시지를 표시합니다.

아래에는 비결정적 스키마의 몇 가지 예가 더 나와 있습니다. 첫 번째 예에서는 선택적 요소를 다룹니다. 이러한 경우는 XDR-XSD 변환기에서 자주 발생합니다. 그 이유는 두 스키마 언어의 기본 카디널리티가 서로 다르기 때문입니다. 고려해야 할 첫 번째 경우는 xsd:choice 및 xsd:sequence 요소를 사용하여 선언된 선택적 요소입니다. 이름이 동일한 요소가 두 개 이상 있고 그 사이에 선택적 요소만 있는 경우가 아니라면 xsd:sequence 요소에서 선언된 선택적 요소의 유효성 검사는 일반적으로 올바르게 수행됩니다. 예를 들면 다음과 같습니다.

<xsd:element name="container"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element ref="aNode" /> 
            <xsd:element ref="anotherNode" minOccurs="0"/> 
            <xsd:element ref="aNode" /> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

이 스키마 세그먼트가 비결정적인 이유를 알아보기 위해 다음과 같은 유효하지 않은 XML 조각이 있는 경우를 가정해 보겠습니다.

<container> 
    <aNode/> 
    <aNode/> 
    <anotherNode/> 
</container>

이 조각을 살펴보면 이 조각이 유효하지 않은 이유를 알 수 있습니다. <anotherNode> 요소 앞에 하나만 허용되는 <aNode> 요소가 두 개 있기 때문입니다.

이번에는 다음 XML 인스턴스의 유효성을 검사해야 하는 경우를 가정해 보겠습니다.

<container> 
    <aNode/> 
    <aNode/> 
</container>

중요한 점은 이 인스턴스가 유효한지 여부를 파악하는 것입니다. <aNode> 요소가 하나만 허용되는 위치에 두 개가 있습니까? 아니면 <aNode> 요소가 허용되는 위치에 하나가 있고 또 다른 허용되는 위치에 또 하나가 있습니까? 이를 알 수 있는 방법이 없기 때문에 해당 스키마는 비결정적입니다.

마찬가지로 xsd:choice 요소에서 선언되는 선택적 요소의 경우에도 일반적으로 문제가 됩니다. 다음과 같은 간단한 예에서 선택이 선택적 요소 없이 한 번 발생했는지, 아니면 전혀 발생하지 않았는지를 파악할 수 있는 방법이 없습니다.

<xsd:choice> 
    <xsd:element name="node" minOccurs="0"/> 
</xsd:choice>

문제가 될 수 있는 마지막 사례는 <xsd:any namespace="##other"/>에서 사용하는 것과 같이 네임스페이스 정의 없이 xsd:sequence 요소 뒤에 xsd:any 요소를 사용하는 경우입니다. 이러한 구문은 특히 선택적 요소 뒤에 사용되는 경우 문제가 될 수 있습니다. 이전 예를 다시 사용하여 마지막 노드만 xsd:any 요소로 변경해 보면 앞에서 비결정주의에 대해 설명한 모든 내용이 다음과 같이 계속 적용되는 것을 알 수 있습니다.

<xsd:element name="container"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:element ref="aNode" /> 
            <xsd:element ref="anotherNode" minOccurs="0"/> 
            <xsd:any />     
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

잘못된 열거 값

XSD 스키마는 일반적으로 실제 인스턴스 문서의 유효성을 검사할 때까지 형식 유효성 검사를 수행하지 않습니다. 단, 스키마에 열거가 있는 경우는 예외입니다. 이 경우에는 스키마에서 열거 형식에 대해 열거 값의 유효성을 검사하여 올바른 노드 값인지 확인합니다. 다음은 이와 관련된 두 가지 예입니다.

<xsd:simpleType name="showTimes"> 
    <xsd:restriction base="xsd:time"> 
        <xsd:enumeration value="18:30:00"/> 
        <xsd:enumeration value="20:45:00"/> 
        <xsd:enumeration value="eleven o'clock"/> 
    </xsd:restriction> 
</xsd:simpleType>

"eleven o'clock"이 xsd:time 형식의 요소에 대해 유효한 값이 아니므로 이 스키마는 유효하지 않습니다.

다음은 보다 복잡한 예입니다.

<xsd:simpleType name="concession"> 
    <xsd:restriction base="xsd:NMTOKEN"> 
        <xsd:enumeration value="GummyBears"/> 
        <xsd:enumeration value="SnowCaps"/> 
        <xsd:enumeration value="M&Ms"/> 
    </xsd:restriction> 
</xsd:simpleType>

이 예가 유효하지 않은 이유를 이해하려면 xsd:NMTOKEN 형식이 정의되는 방식을 이해해야 합니다. W3C 데이터 형식 설명에서는 NMTOKEN 형식을 "An NMTOKEN (name token) is any mixture of name characters.(NMTOKEN(이름 토큰)은 임의의 이름 문자 혼합이다.)"라고 정의합니다.

좀 더 자세히 살펴보면 '&'는 유효한 이름 문자가 아니므로 "M&Ms"는 NMTOKEN 형식으로 유효하지 않다는 것을 알 수 있습니다.

빈 sequence 또는 choice 요소

MSXML에서는 다음 예에 나와 있는 것처럼 빈 xsd:choice 또는 xsd:sequence 요소가 포함된 스키마 선언에 대한 오류가 발생하는 경우가 있습니다.

<xsd:element name="emptyContainer"> 
    <xsd:complexType> 
        <xsd:choice /> 
    </xsd:complexType> 
</xsd:element>

빈 <xsd:choice /> 태그를 제거하면 이 문제가 해결됩니다.

정규식

MSXML 5.0에서는 로드 시 정규식 패턴의 유효성을 검사하는 데 문제가 있을 수 있습니다. 정규식은 복잡할 수 있으며 정규식을 사용하는 경우 주의해야 합니다. 모든 XSD 파서는 유연한 정규식 언어를 사용하는 것으로 보입니다. 즉, 공식 XSD 정규식 언어뿐 아니라 기타 정규식 언어의 요소도 구현합니다. InfoPath 양식 디자이너에서 정규식을 구문 분석하는 데 문제가 있는 경우 InfoPath에서 생성하는 예제 데이터가 유효하지 않거나 예제 데이터가 전혀 생성되지 않을 수 있습니다. 디자인 타임에는 InfoPath에서 서식 지정용 예제 데이터만 사용하므로 이러한 문제가 있어도 괜찮습니다. 그러나 MSXML에서 지원하지 않는 정규식을 사용하는 경우에는 사용자가 양식을 작성할 때 InfoPath에서 해당 정규식에 대해 값의 유효성을 검사할 수 없습니다. XML 스키마 제0부: 입문 제2판 (영문)에서는 XSD 정규식에서 지원되는 항목에 대해 설명합니다. XSD 정규식 및 유니코드 수준 1 정규식에 대한 자세한 내용은 유니코드 홈 페이지 (영문)를 참조하십시오.

targetNamespace 특성 문제

XSD에서는 기본적으로 targetNamespace 특성이 최상위 선언만 참조하지만 attributeFormDefault=qualified 및 elementFormDefault=qualified를 설정하여 이러한 기본 동작을 다시 정의할 수 있습니다. 예를 들어 다음과 같은 XSD가 있는 경우를 가정해 보겠습니다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://ns" > 
    <xsd:element name="root"> 
        <xsd:complexType> 
            <xsd:sequence> 
                <xsd:element name="local"/> 
            </xsd:sequence> 
        </xsd:complexType> 
    </xsd:element> 
</xsd:schema>

그리고 XML 인스턴스 문서가 다음 예와 유사합니다.

<ns:root xmlns:ns="http://ns"> 
    <local/> 
</ns:root>

로컬 정의의 경우 기본적으로 정규화를 사용하지 않도록 설정되므로 대상 네임스페이스가 필요하지 않습니다. 그러나 로컬 정의를 글로벌 정의로 변경하는 경우에는 참조가 네임스페이스 접두사를 사용하여 정규화되어야 합니다. 예를 들어 다음 스키마는 유효하지 않습니다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://ns" > 
    <xsd:element name="root"> 
        <xsd:complexType> 
            <xsd:sequence> 
                <xsd:element ref="global"/> 
            </xsd:sequence> 
        </xsd:complexType> 
    </xsd:element> 
 
    <xsd:element name="global"/> 
</xsd:schema>

네임스페이스 "http://ns"에 "global"이 있으므로 이 스키마는 유효하지 않습니다. 기본 네임스페이스가 "http://ns"가 아니므로 단순한 ref="global"은 인식되지 않습니다. 이 문제를 해결하려면 대상 네임스페이스에 대한 접두사를 추가하고 모든 글로벌 참조 및 형식 사용 시 사용해야 합니다. 수정된 스키마는 다음과 같습니다.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"  
    xmlns:ns="http://ns" targetNamespace="http://ns" > 
    <xsd:element name="root"> 
        <xsd:complexType> 
            <xsd:sequence> 
                <xsd:element ref="ns:global"/> 
            </xsd:sequence> 
        </xsd:complexType> 
    </xsd:element> 
 
    <xsd:element name="global"/> 
</xsd:schema>

스키마에 targetNamespace 특성이 지정되어 있는 경우 모든 글로벌 참조가 올바른 네임스페이스 접두사를 사용하여 정규화되어 있는지 확인합니다.

XML 처리 명령 인코딩(유니코드와 ANSII 비교)

XML은 유니코드 문자 집합만 지원합니다. 따라서 ANSII 문자를 사용하는 파일을 저장하는 경우 정보가 손실될 수 있습니다. 그러나 특정 용도의 경우 파일을 UTF-16으로 저장하는 것은 불필요한 작업일 수 있습니다. XML 판독기의 구현 비용을 절감하려면 XML 작성자가 최상위 XML 처리 명령에 사용할 인코딩을 명시해야 합니다. 다음과 같은 처리 명령을 볼 수 있습니다.

xml version="1.0" encoding="UTF-8"

이 처리 명령 태그는 파일의 인코딩이 UTF-8임을 지정합니다. 해당 파일 인코딩이 처리 명령 태그에 명시된 인코딩과 동일한지 확인해야 합니다. 파일의 바이트를 확인하고 유니코드 바이트 순서 표시를 찾아보면 인코딩을 파악할 수 있습니다. 그러나 더 간편한 방법이 있습니다. XSD 스키마를 여는 데 문제가 있는 경우 인코딩을 "UTF-8"로 지정하고 메모장과 같은 텍스트 편집기에서 해당 파일을 연 다음 UTF-8 인코딩(메모장의 경우 다른 이름으로 저장 대화 상자의 인코딩 드롭다운 목록 제공)을 사용하여 저장합니다. 그래도 파일을 여는 데 문제가 있으면 인코딩 문제가 아닙니다.

xsd:all 요소 내 maxOccurs 특성

XML 스키마 권장 사항에서 비결정주의가 정의되는 방법으로 인해 xsd:all 요소 내 xsd:element 요소의 maxOccurs 특성에 대해 유효한 유일한 값은 1입니다. 예를 들어 다음 내용은 유효합니다.

<xsd:all> 
    <xsd:element name="x" minOccurs="0"/> 
    <xsd:element name="docs" minOccurs="0"/> 
</xsd:all>

그러나 다음 예는 유효하지 않습니다.

<xsd:all>     
    <xsd:element name="x" minOccurs="0" maxOccurs="unbounded"/> 
    <xsd:element name="docs" minOccurs="0" maxOccurs="unbounded"/> 
</xsd:all>

이 예는 유효성 검사 시스템에서 <x/> 항목이 두 번 단일 선언에 매핑되는지, 아니면 해당 선언과 또 다른 유효하지 않은 정의에 매핑되는지 확인할 수 없기 때문에 유효하지 않습니다. 마찬가지로 하나의 <xsd:all> 태그에 동일한 이름의 요소를 두 개 포함할 수 없습니다.

또한 이 예에서는 포함하는 요소 내부에 <x/> 및 <docs/> 노드를 원하는 순서로 원하는 수만큼 포함할 수 있습니다. 이 구문은 유효하지 않지만 해결 방법이 있습니다. xsd:choice 요소를 사용하면 다음 예에 나와 있는 것과 같이 동일한 결과를 얻을 수 있습니다.

<xsd:choice minOccurs="0" maxOccurs="unbounded"> 
    <xsd:element name="x" /> 
    <xsd:element name="docs" /> 
</xsd:choice>

InfoPath의 XSD 편집 및 작성 방법

다음 섹션의 두 가지 예는 스키마를 편집 또는 작성하여 InfoPath에서 특정 결과를 생성하는 방법을 보여 줍니다.

필드 작업창에 사용자 정의 요소 삽입 허용

사용자 정의 요소가 필드 작업창의 상위 요소 아래에 표시되도록 허용하려면 해당 상위 요소 아래에 xsd:any 요소를 삽입해야 합니다. <your_node_name> 내부에 사용자 정의 요소가 삽입되도록 허용하려면 다음과 같이 XSD 선언을 수행해야 합니다.

<xsd:element name="your_node_name"> 
    <xsd:complexType> 
        <xsd:sequence> 
            <xsd:any namespace="##any | ##other"  
                minOccurs="0" maxOccurs="unbounded"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

사용자 정의 특성도 허용하려는 경우에는 요소 선언에 <xsd:anyAttribute namespace="##any | ##other"/>를 추가해야 합니다.

InfoPath 디자인 모드 및 편집 모드에서 서식 있는 텍스트 요소 바인딩 허용

Rich Text Box 컨트롤에 바인딩될 수 있는 요소를 선언하려면 다음 예에 나와 있는 것과 같이 네임스페이스 특성이 "http://www.w3.org/1999/xhtml"로 설정된 xsd:any 요소를 포함하는 다음과 같은 양식이 있어야 합니다.

<xsd:element name="your_node_name"> 
    <xsd:complexType mixed="true"> 
        <xsd:sequence> 
            <xsd:any namespace="http://www.w3.org/1999/xhtml"  
                minOccurs="0" maxOccurs="unbounded"/> 
        </xsd:sequence> 
    </xsd:complexType> 
</xsd:element>

결론

외부에서 작성된 XML 스키마(.xsd) 파일에 기반한 XML 양식 솔루션 디자인에 대한 InfoPath 지원을 활용하면 업계 표준 스키마 또는 회사나 조직에서 만든 사용자 지정 스키마와 함께 사용할 수 있는 양식 서식 파일을 만들 수 있습니다. 이 문서의 정보를 사용하여 InfoPath와 호환되는 사용자 지정 XSD 스키마 파일을 만들고 외부에서 작성된 XSD 파일을 InfoPath 디자인 환경으로 로드할 때 발생할 수 있는 일반적인 문제를 해결할 수 있습니다.

참고 항목

기타 리소스

W3C XML 스키마 (영문일 수 있음)

W3C XML 스키마 입문 (영문일 수 있음)

W3C XML 스키마 구조 참조(영문일 수 있음)

W3C XML 스키마 데이터 형식 참조(영문일 수 있음)

XML 스키마 자습서(영문일 수 있음)

XML 개발자 센터(영문일 수 있음)