2012-08-13 5 views
4

XSD에 정의 된 유효한 열거 옵션을 기반으로 일부 요소를 생성해야하는 XML 파일을 변환 중입니다.XSL에서 XSD에서 데이터 추출

<options> 
    <chosenOption>USERCHOICE</chosenOption> 
</options> 
: 당신이 다음과 같습니다 상상할 수

<xs:simpleType name="optionType" nillable="true"> 
    <xs:restriction base="xs:string"> 
     <xs:maxLength value="50"/> 
     <xs:enumeration value="USERCHOICE"> 
     </xs:enumeration> 
     <xs:enumeration value="DEFAULT"> 
     </xs:enumeration> 
     </xs:restriction> 
</xs:simpleType> 
... 
<xs:element name="chosenOption" type='optionType'/> 
... 
<xs:element name="availableOption" type='optionType'/> 

이 입력은, 선택한 옵션이 포함됩니다 :

가정하자 나는 형태와 같은 요소 뭔가를 선언하는 XSD가 하 수있는 방법이 거기에있다

<options> 
    <chosenOption>USERCHOICE</chosenOption> <!-- This comes from incoming XML --> 

    <!-- This must be a list of ALL possible values for this element, as defined in XSD --> 
    <availableOptions> 
     <availableOption>USERCHOICE</availableOption> 
     <availableOption>DEFAULT</availableOption> 
    </availableOptions> 
</options> 

:

나는 다음과 같습니다 출력이 필요합니다 XSL은 XSD에서 열거 형 값 USERCHOICEDEFAULT을 추출하여 출력에서 ​​생성합니까?

이것은 WebSphere 6에서 실행되며 XSLT 1.0 엔진에서 사용됩니다. :(

는 (스키마 파일은 자주 변경되지 않습니다하지만 것이다 변경 이제 다음과 차라리에만 스키마 파일 및 XSLT 대신 업데이트의 스키마 파일을 업데이트해야 할 것) 여기

+0

내가 해결하는 것 일관성을 유지할 수있는 게시판, 지금 XSD는'optionType'을 보여주고 XML은'selectedOption'을 보여줍니다. 그 두 개 짜기 야? 인간은 당신의 질문에 기초하여 어떤 추론을 할 수 있습니다. 명시 적 메타 데이터 또는 규칙을 통해 변환을 명확하게해야합니다. XSD의 위치, XML 태그 이름 (또는 XPath) 및 적절한 XML 스키마 유형을 연결해야합니다. –

+0

@PetruGardea : 좋은 지적입니다. 실제 예제는 좀 더 복잡합니다. 나는 그것을 정리하려고 무언가를 엉망으로 만들었습니다. 기본 요소는 들어오는 요소가 열거 형의 값으로 제한된다는 것입니다. 변형 된 XML의 소비자는 요소 *가 제한 될 수있는 모든 사용 가능한 옵션 목록을 필요로합니다. – FrustratedWithFormsDesigner

+0

순수 XSLT 솔루션의 경우 XSD를 인식하는 XSLT 2.0 엔진에 액세스해야합니다. [Saxon-EE] (http://www.saxonica.com/feature-matrix.html)는 여기 내 마음에 - 그건 확실합니다. 그리고 심지어는 상호 운용이 가능하고 XSD 만 수정할 수있는 목표를 달성 할 수 있을지는 의문입니다. 반면에 예를 들어, .NET에서는 XSLT없이 이러한 솔루션을 손쉽게 구축 할 수 있습니다. XSD를 유지해야하는 유일한 아티팩트로 사용할 수 있습니다. –

답변

4

이입니다 위의 샘플. 당신이 알려, 그 조정이 도움이 필요한 경우가. 다를 수있는 방법에 따라 불통에 대한 사용자의 입력 XML 및 XSD가 간단하다고 가정 프로토 타입.

<?xml version="1.0" encoding="UTF-8"?> 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    xmlns:xs="http://www.w3.org/2001/XMLSchema" 
    exclude-result-prefixes="xs" 
    version="1.0"> 

    <xsl:variable name="xsd" select="document('mySchema.xsd')"/> 

    <xsl:template match="/options"> 
     <xsl:copy> 
     <xsl:for-each select="*"> 
      <xsl:variable name="eltName" select="local-name()"/> 
      <xsl:copy-of select="." /> 
      <availableOptions> 
       <xsl:variable name="optionType" 
        select="$xsd//xs:element[@name = $eltName]/@type"/> 
       <xsl:apply-templates 
        select="$xsd//xs:simpleType[@name = $optionType]/ 
         xs:restriction/xs:enumeration"/> 
      </availableOptions> 
     </xsl:for-each> 
     </xsl:copy> 
    </xsl:template> 

    <xsl:template match="xs:enumeration"> 
     <availableOption><xsl:value-of select="@value" /></availableOption> 
    </xsl:template> 
</xsl:stylesheet> 
+2

충분한 일반성에 대한 @ Petru의 우려를 공유합니다. (예 : 복잡한 스키마 변경에 대한) 전체적인 보편성이 필요하지 않은 경우 위의 내용을 제공합니다. 질문에 대한 설명에서 얻은 인상은 스키마가 단순하고 예측 가능한 방식으로 만 변화한다는 것입니다. 그러나 틀릴 수도 있습니다. – LarsH

+1

내 의견을 설명하기 위해 코드를 사용합니다. 이상적으로는 XSLT와 제작 스타일을 분리하려고합니다. XSD가 변경되어 PSVI에 영향을주지 않습니다 (다른 XSD가 동일한 XML의 유효성을 검사 할 수 있음). 귀하의 코드는 XSD가 어떻게 작성되었는지 정확하게 알기 위해 많이 의존합니다. 그런 다음 단순히 값을 하드 코드하지 않는 이유는 무엇입니까? 제가 이것을 말하고있는 이유는 실제 구현을 설명하기 위해서입니다. 실제로 아티펙트가 아닌 경우 아티팩트가 XSLT의 XSD와 분리된다는 보안에 대한 잘못된 인식을 제공합니다. –

+1

일반에 대한 의견을 보았습니다. +1! 나는 그것을 더 잘 말하지 못했습니다 ... –