스키마 (xs : redefine 사용)의 확장 요소가 세 번째 스키마로 가져올 때 잘못된 네임 스페이스가 있습니다.

Question

다음은 시나리오입니다. BizTalk를 사용하여 ESB를 구현하는 중입니다. BizTalk를 통해 전달되는 메시지의 프로세스 헤더로 사용할 스키마가 있습니다. 헤더 스키마는 모든 표준 스키마로 가져옵니다. 프로세스 헤더 요소가 승격되어 라우팅에 사용됩니다. 이 접근법은 잘 작동합니다. 하지만 이제 특정 메시지 유형에 대해이 원래 프로세스 헤더 스키마를 원합니다. 나는 xs : redefine을 사용하여 메인 프로세스 헤더를 수정하고 추가 요소를 추가 할 것이라고 생각했다. 그러나 표준 스키마로 재정의 된 스키마를 가져올 때 새로운 프로세스 헤더 요소는 확장되는 프로세스 헤더 스키마의 네임 스페이스 대신 표준 스키마의 네임 스페이스를 사용합니다. 여기 일어나고 있는지의 일부 단순화 된 예들이다 : 1. OriginalProcessSchema.xsd

<?xml version="1.0" encoding="utf-16"?> 
<xs:schema xmlns:mh="http://ProcessHeaderNamespace" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" elementFormDefault="qualified" targetNamespace="http://ProcessHeaderNamespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:element name="MessageHeader" type="mh:ProcessHeader"> 

    </xs:element> 
    <xs:complexType name="ProcessHeader"> 
     <xs:sequence> 
     <xs:element name="Field1" type="xs:string" /> 
     <xs:element name="Field2" type="xs:string" /> 
     </xs:sequence> 
    </xs:complexType> 

</xs:schema> 

2.ExtendedProcessHeaderSchema.xsd - 처음

<?xml version="1.0" encoding="utf-16"?> 
<xs:schema xmlns:mh="http://ProcessHeaderNamespace" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" elementFormDefault="qualified" targetNamespace="http://ProcessHeaderNamespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:redefine schemaLocation=".\OriginalProcessSchema.xsd"> 
    <xs:complexType name="ProcessHeader"> 
     <xs:complexContent mixed="false"> 
     <xs:extension base="mh:ProcessHeader"> 
      <xs:sequence> 
      <xs:element name="Field3" type="xs:string" /> 
      </xs:sequence> 
     </xs:extension> 
     </xs:complexContent> 
    </xs:complexType> 
    </xs:redefine> 
</xs:schema> 

3.CanonicalSchema.xsd을 재정의 한 - 두 번째 스키마를 가져옵니다. 나는 모두가 좋아 보인다 Visual Studio에서 두 번째 파일의 인스턴스를 생성 할 경우

<?xml version="1.0" encoding="utf-16"?> 
<xs:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://ProductNamespace" xmlns:ph="http://ProcessHeaderNamespace" targetNamespace="http://ProductNamespace" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
    <xs:import schemaLocation=".\ExtendedProcessHeaderSchema.xsd" namespace="http://ProcessHeaderNamespace" /> 
    <xs:annotation> 
    <xs:appinfo> 
     <b:references> 
     <b:reference targetNamespace="http://ProcessHeaderNamespace" /> 
     </b:references> 
    </xs:appinfo> 
    </xs:annotation> 
    <xs:element name="Product"> 
    <xs:complexType> 
     <xs:sequence> 
     <xs:element name="ProcessHeader" type="ph:ProcessHeader" /> 
     <xs:element name="ProductDate"> 
      <xs:complexType> 
      <xs:sequence> 
       <xs:element name="Field4" type="xs:string" /> 
       <xs:element name="Field5" type="xs:string" /> 
       <xs:element name="Field6" type="xs:string" /> 
      </xs:sequence> 
      </xs:complexType> 
     </xs:element> 
     </xs:sequence> 
    </xs:complexType> 
    </xs:element> 
</xs:schema> 

, 모든 요소는 같은 네임 스페이스에 있습니다 그러나

<ns0:MessageHeader xmlns:ns0="http://ProcessHeaderNamespace"> 
    <ns0:Field1>Field1_0</ns0:Field1> 
    <ns0:Field2>Field2_0</ns0:Field2> 
    <ns0:Field3>Field3_0</ns0:Field3> 
</ns0:MessageHeader> 

나는 세 번째 파일의 인스턴스를 생성하는 경우,이 내가 보는 것입니다 :

<ns0:Product xmlns:ns0="http://ProductNamespace"> 
    <ProcessHeader> 
    <ns1:Field1 xmlns:ns1="http://ProcessHeaderNamespace">ph:Field1_0</ns1:Field1> 
    <ns1:Field2 xmlns:ns1="http://ProcessHeaderNamespace">ph:Field2_0</ns1:Field2> 
    <ns0:Field3>Field3_0</ns0:Field3> 
    </ProcessHeader> 
    <ProductDate> 
    <Field4>Field4_0</Field4> 
    <Field5>Field5_0</Field5> 
    <Field6>Field6_0</Field6> 
    </ProductDate> 
</ns0:Product> 

Field3은 제품 표준 (이 예에서는 ProductNamespace)의 네임 스페이스에 있습니다. ProcessHeader 네임 스페이스에 있어야합니다. 동료가 다른 툴 (oXygen xml)을 사용하여 이것을 보았고 실제로 프로세스 헤더에있는 모든 요소의 네임 스페이스가 동일합니다. Visual Studio/Biztalk의 버그입니까? 누구든지 여기에서 무슨 일이 일어나고 있는지에 대해 밝히거나 해결할 수 있습니까?

Visual Studio 2013 및 BizTalk Server 2013을 사용하고 있습니다.

Answer 1

이 질문에 답변 해 드리겠습니다. 이 문제를 해결하려고해도이 문제를 해결할 수 있습니다.

의미, '확장 가능한'스키마 프레임 워크를 만들려고한다는 것은 가치가있는 것보다 더 큰 문제입니다. cXml, ebXml 등은 모두이 작업을 수행하며 은 멍청하고 어리 석으므로으로 작업하기가 어렵습니다.

이 불필요하고 값 비싼 복잡성은 JSON이 그렇게했던 이유 (IMO)입니다. 하나 개 XS를 사용

는

: 헤더에 대한 나는 심지어 빈 네임 스페이스를 사용하여 고려하는 모든입니다 포함되어 있습니다. BizTalk: Simplify BizTalk Dev by Using the Empty Namespace