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

Discussion in 'XML' started by Tedros.G@googlemail.com, Jun 14, 2007.

  1. Guest

    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">
    <xsl:eek:utput 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>
    <xsl:eek:therwise>

    </xsl:eek:therwise>
    </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>

    <xsl:eek:therwise>

    </xsl:eek:therwise>

    </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>

    <xsl:eek:therwise>

    </xsl:eek:therwise>

    </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>

    <xsl:eek:therwise> </xsl:eek:therwise>

    </xsl:choose>

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



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


    Thanks in advance
    Ted.
    , Jun 14, 2007
    #1
    1. Advertising

  2. Peter Flynn Guest

    wrote:
    > 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
    Peter Flynn, Jun 14, 2007
    #2
    1. Advertising

  3. Dag Sunde Guest

    Peter Flynn wrote:
    > wrote:
    >> 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.
    >

    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.

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

    >
    > Nope.


    Never try to "understand" brokent files just to be helpful...
    You will get a feature-creep that will overwhelm you.
    Dag Sunde, Jun 14, 2007
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jeremy Sanchez
    Replies:
    0
    Views:
    432
    Jeremy Sanchez
    Dec 12, 2003
  2. Donald Powell
    Replies:
    0
    Views:
    427
    Donald Powell
    Dec 12, 2003
  3. greg
    Replies:
    2
    Views:
    408
    Marc Hoeppner
    Jul 27, 2003
  4. M O J O
    Replies:
    2
    Views:
    274
    M O J O
    Aug 6, 2003
  5. Prince

    Tough Problem

    Prince, Jan 26, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    395
    Michael Earls
    Jan 26, 2004
Loading...

Share This Page