Tough transform to solve.........

[Tedros.G]

Okay this is a slightly tricky one for us newbies, butI'm guessing
it'll be breeze for ou experts!

Problem:
You recieve a xml message which conforms to a common schema.
Everything is great and your clients (who send you their data based on
this agreed schema), do everything works as agreed and planned.
Over the next few months a few clients suddenly decide to add extra
nodes, therby breaking the schema validation. Then another client does
the same and adds their own nodes to the data. So now you have two
choices:

1. Stop accepting the broken xml.
2. Transform the broken xml into a schema conforming xml, by removing
the error nodes.

The only problem is you don't know what naughty error nodes can show
up at any time. However we know from the schema what nodes are good
and won't break the schema.


Eample:

In the following example how could I make sure only the <GOODNODES>
are kept and all the BADNODES are thrown away (remember there could be
man many BADNODES and to make things worse you just don't know what
they will be called).


In this example I have 2 bad nodes.

<?xml version="1.0" encoding="utf-16"?>
<CLIENTDATA xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="LONDON"
VERSION="1.2">
<HEADER>
<OPERATION NAME="PRICE">
<USERNAME>BOBSMITH</USERNAME>
<HOSTNAME>LONDON</HOSTNAME>
</OPERATION>
</HEADER>

<GOODNODE1>

<GOODNODE2 TYPE="MID" USEREDITED="false">

<GOODNODE3>
<CHILD1 TYPE="MID" USEREDITED="false">
<SWAP TYPE="MID" USEREDITED="false">19.16</SWAP>
</CHILD1>
</GOODNODE3>

<BADNODE1 TYPE="MID" USEREDITED="false">
<RUBBISH TYPE="RUBBISH1" USEREDITED="RUBBISH2">0000</RUBBISSH>
</BADNODE1>

<BADNODE2 TYPE="MID" USEREDITED="false">
<RUBBISH TYPE="RUBBISH1" USEREDITED="RUBBISH2">0000</RUBBISSH>
</BADNODE2>

<GOODNODE4>
<CHILD1 TYPE="MID" USEREDITED="false">
<SWAP TYPE="MID" USEREDITED="false">19.16</SWAP>
</CHILD1>
</GOODNODE4>
</GOODNODE2>
</GOODNODE1>

</CLIENTDATA>



The closest I could was to do something like this (close but I get
RUBBISH1RUBBISH2 etc embeded in the result):


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/
Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xslutput method="xml" version="1.0" encoding="UTF-8" indent="yes"/
<xsl:template match="@*|CLIENTDATA">
<xsl:copy>
<xsl:choose>
<xsl:when test="name()='CLIENTDATA' ">
<xsl:apply-templates select="@*|node()"/>
</xsl:when>
<xsltherwise>

</xsltherwise>
</xsl:choose>
</xsl:copy>
</xsl:template>

<xsl:template match="@*|/CLIENTDATA/HEADER">
<xsl:copy>
<xsl:choose>
<xsl:when test="name()='HEADER' ">
<xsl:copy-of select="@*|/CLIENTDATA/HEADER"/>
</xsl:when>

<xsltherwise>

</xsltherwise>

</xsl:choose>
</xsl:copy>
</xsl:template>

<xsl:template match="text()|@*|/CLIENTDATA/GOODNODE1">
<xsl:copy>
<xsl:choose>
<xsl:when test="name()='GOODNODE1'">
<xsl:apply-templates select="@*|node()"/>
</xsl:when>

<xsltherwise>

</xsltherwise>

</xsl:choose>
</xsl:copy>
</xsl:template>

<xsl:template match="GOODNODE2">
<xsl:choose>
<xsl:when test="name()='GOODNODE2'">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>

<xsl:copy-of select="@*|/CLIENTDATA/GOODNODE1/GOODNODE2/
GOODNODE3"/>

<xsl:copy-of select="@*|/CLIENTDATA/GOODNODE1/GOODNODE2/
GOODNODE4"/>

</xsl:when>

<xsltherwise> </xsltherwise>

</xsl:choose>

</xsl:template>
</xsl:stylesheet>



Is there a more correct and elegant way to do this??????


Thanks in advance
Ted.

 

[Peter Flynn]

Okay this is a slightly tricky one for us newbies, butI'm guessing
it'll be breeze for ou experts!

Problem:
You recieve a xml message which conforms to a common schema.
Everything is great and your clients (who send you their data based on
this agreed schema), do everything works as agreed and planned.
Over the next few months a few clients suddenly decide to add extra
nodes, therby breaking the schema validation. Then another client does
the same and adds their own nodes to the data. So now you have two
choices:

1. Stop accepting the broken xml.

Yes. Tell them their data is non-conformant and can't be processed.
If they want to add stuff, write them a new Schema. Bill them.

Sometimes you have to hit them with a lart until they comply.

2. Transform the broken xml into a schema conforming xml, by removing
the error nodes.

Nope.

///Peter

 

[Dag Sunde]

Yes. Tell them their data is non-conformant and can't be processed.
If they want to add stuff, write them a new Schema. Bill them.

Sometimes you have to hit them with a lart until they comply.

Agreed! :-D

The clients DO have access to the Schema, don't they?
They should be informed that your application is adhering _strictly_
to that Schema, and will reject anything that doesn't validate.

That's why the schema is there in the first place, and why _both_
parties have access to it.

Nope.

Never try to "understand" brokent files just to be helpful...
You will get a feature-creep that will overwhelm you.