Friday, 15 January 2010

Transforming a XML according to a XSD using XSLT -



Transforming a XML according to a XSD using XSLT -

i create xslt can transform xml of elements , attributes not defined in xsd excluded in output xml (from xslt).

lets have xsd.

<xs:element name="parent"> <xs:complextype> <xs:sequence> <xs:element name="keptelement1" /> <xs:element name="keptelement2" /> </xs:sequence> <xs:attribute name="keptattribute1" /> <xs:attribute name="keptattribute2" /> </complextype> </xsd:element>

and have input xml

<parent keptattribute1="kept" keptattribute2="kept" notkeptattribute3="not kept" notkeptattribute4="not kept"> <notkeptelement0>not kept</notkeptelement0> <keptelement1>kept</keptelement1> <keptelement2>kept</keptelement2> <notkeptelement3>not kept</notkeptelement3> </parent>

then have output xml looking this.

<parent keptattribute1="kept" keptattribute2="kept"> <keptelement1>kept</keptelement1> <keptelement2>kept</keptelement2> </parent>

i able specifying elements, far xslt skills reach. have problem doing elements , attributes.

you have 2 challenges here: (1) identifying set of element names , attributes declared in schema, appropriate context info local declarations, , (2) writing xslt retain elements , attributes match names or names-and-contexts.

there 3rd issue, namely specifying mean "elements , attributes (or not) defined in xsd schema". purposes of give-and-take i'll assume mean elements , attributes bound element or attribute declarations in schema, in validation episode (a) rooted @ arbitrary point in input document tree , (b) starting top-level element declaration or attribute declaration. assumption means several things. (a) local element declarations match things in context -- in example, keptelement1 , keptelement2 retained when children of parent, not otherwise. (b) there no guarantee elements in input in fact bound element declarations in question: if 1 of ancestors locally invalid, things complicated fast both in xsd 1.0 , in 1.1. (c) don't allow starting validation named type definition; could, doesn't sound if that's you're interested in. (d) don't allow starting validation local element or attribute declarations.

with assumptions explicit, can turn problem.

the first task requires create list of (a) elements , attributes top-level declarations in schema, , (b) elements , attributes reachable them. top-level declarations, need record kind of object (element or attribute) , expanded name. local objects, need kind of object , total path top-level element declaration. sample schema, list (a) consists of

element {}parent

(i using convention of writing expanded names namespace name in braces; phone call clark notation, james clark.)

list (b) consists of

element {}parent/{}keptelement1 element {}parent/{}keptelement2 attribute {}parent/{}keptattribute1 attribute {}parent/{}keptattribute2

in more complicated schemas, there amount of bookkeeping go through process of generating list.

your sec task write xslt stylesheet keeps elements , attributes in list , drops rest. (i'm assuming here when drop element, drop contents, too; question talks elements, not tags.)

for each element in list, write appropriate identity transform, using context given in list:

<xsl:template match="parent"> <xsl:copy> <xsl:apply-templates select="@* | node()"/> </xsl:copy> </xsl:template>

you can write separate template each element, or can write several elements match pattern:

<xsl:template match="parent | parent/keptelement1 | parent/keptelement2"> <xsl:copy> <xsl:apply-templates select="@* | node()"/> </xsl:copy> </xsl:template>

for each attribute in list, same:

<xsl:template match="parent/@keptattribute1"> <xsl:copy/> </xsl:template>

override default templates elements , attributes, suppress other elements , attributes:

<xsl:template match="*|@*"/>

[alternatively, suggested drmacro, can write function or named template in xslt consult list generated in task 1, instead of writing out repetitive templates explicit match patterns. depending on background, may find that approach makes easier, or harder, understand stylesheet doing.]

xml xslt xsd

No comments:

Post a Comment