"Relational" behavior with XML

[QuinTech]

Hi, all. I am importing some XML into a large FM solution. One of the XML elements references another element elsewhere in the file:

<?xml version="1.0"?>

<Document>

<Transaction>

<Client>

<Matter>

<Assets>

<Miscellaneous>

<AssetID>35</AssetID>

<Value>56000</Value>

</Miscellaneous>

</Assets>

<Bequests>

<Bequest>

<AssetPercentage>75</AssetPercentage>

<AssetID>35</AssetID>

</Bequest>

</Bequests>

</Matter>

</Client>

</Transaction>

</Document>

I can import the <Miscellaneous> element into FM using one transformation, then import the <Bequest> element into another file using a different transformation, do some multiplication, and i come up with a total value for the bequest of 42000.

Document/Transaction/Client/Matter/Assets/Miscellaneous/Value = 56000

Document/Transaction/Client/Matter/Bequests/Bequest/AssetPercentage = 75



56000 * ( 75 / 100 ) = 42000

This is cumbersome. I cannot change the original XML. Is there a simpler method than importing to two separate FM files?

Jerry

[QuinTech]

Hi, all. I am importing some XML into a large FM solution. One of the XML elements references another element elsewhere in the file:

<?xml version="1.0"?>

<Document>

<Transaction>

<Client>

<Matter>

<Assets>

<Miscellaneous>

<AssetID>35</AssetID>

<Value>56000</Value>

</Miscellaneous>

</Assets>

<Bequests>

<Bequest>

<AssetPercentage>75</AssetPercentage>

<AssetID>35</AssetID>

</Bequest>

</Bequests>

</Matter>

</Client>

</Transaction>

</Document>

I can import the <Miscellaneous> element into FM using one transformation, then import the <Bequest> element into another file using a different transformation, do some multiplication, and i come up with a total value for the bequest of 42000.

Document/Transaction/Client/Matter/Assets/Miscellaneous/Value = 56000

Document/Transaction/Client/Matter/Bequests/Bequest/AssetPercentage = 75



56000 * ( 75 / 100 ) = 42000

This is cumbersome. I cannot change the original XML. Is there a simpler method than importing to two separate FM files?

Jerry

[QuinTech]

Hi, all. I am importing some XML into a large FM solution. One of the XML elements references another element elsewhere in the file:

<?xml version="1.0"?>

<Document>

<Transaction>

<Client>

<Matter>

<Assets>

<Miscellaneous>

<AssetID>35</AssetID>

<Value>56000</Value>

</Miscellaneous>

</Assets>

<Bequests>

<Bequest>

<AssetPercentage>75</AssetPercentage>

<AssetID>35</AssetID>

</Bequest>

</Bequests>

</Matter>

</Client>

</Transaction>

</Document>

I can import the <Miscellaneous> element into FM using one transformation, then import the <Bequest> element into another file using a different transformation, do some multiplication, and i come up with a total value for the bequest of 42000.

Document/Transaction/Client/Matter/Assets/Miscellaneous/Value = 56000

Document/Transaction/Client/Matter/Bequests/Bequest/AssetPercentage = 75



56000 * ( 75 / 100 ) = 42000

This is cumbersome. I cannot change the original XML. Is there a simpler method than importing to two separate FM files?

Jerry

[QuinTech]

Also, any idea why all the tags disappeared when i originally posted this using the UBBCode for [ code] instead of [ quote]? I though i might control it by turning off HTML for this post, but i can't see where to do that.

J

[QuinTech]

Also, any idea why all the tags disappeared when i originally posted this using the UBBCode for [ code] instead of [ quote]? I though i might control it by turning off HTML for this post, but i can't see where to do that.

J

[QuinTech]

Also, any idea why all the tags disappeared when i originally posted this using the UBBCode for [ code] instead of [ quote]? I though i might control it by turning off HTML for this post, but i can't see where to do that.

J

[Fenton]

I'm not sure what exactly you want to do. I mean, you could just import:

Document/Transaction/Client/Matter/Assets/Miscellaneous/Value

again, with your 2nd XSL, into your Assets table, then do the math in FileMaker.

It would mean an extra field, but so what?

You could alternatively do the math in your 2nd XSL, by adding an element for the total, and importing that:

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest/AssetPercentage">

<xsl:element name="AssetTotal">

<xsl:value-of select=". div 100 *../../../Assets/Miscellaneous/Value"/>

</xsl:element>

</xsl:for-each>

I've not done this before, but the above appears to work. This is assuming there is only 1 of them in each, which is probably not a safe assumption. It would be better to check the AssetID, which is in either:

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

<xsl:variable name="AssID" select="AssetID"/>

<xsl:element name="AssetTotal">

<xsl:value-of select="AssetPercentage div 100 * ../../Assets/Miscellaneous/Value[../AssetID=$AssID]"/>

</xsl:element>

</xsl:for-each>

[i didn't add the FileMaker stuff. The METADATA field is "AssetTotal." And you'd need the requisite <COL><DATA> tags.

Also I'm using "<xsl:for-each>", whereas you might be using separate templates.]

Like I said, I haven't done this math operation before. Also, I just paste the xml code in, it doesn't seem to care about the tags. I believe I have html turned off in my preferences (if there is such).

[Fenton]

I'm not sure what exactly you want to do. I mean, you could just import:

Document/Transaction/Client/Matter/Assets/Miscellaneous/Value

again, with your 2nd XSL, into your Assets table, then do the math in FileMaker.

It would mean an extra field, but so what?

You could alternatively do the math in your 2nd XSL, by adding an element for the total, and importing that:

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest/AssetPercentage">

<xsl:element name="AssetTotal">

<xsl:value-of select=". div 100 *../../../Assets/Miscellaneous/Value"/>

</xsl:element>

</xsl:for-each>

I've not done this before, but the above appears to work. This is assuming there is only 1 of them in each, which is probably not a safe assumption. It would be better to check the AssetID, which is in either:

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

<xsl:variable name="AssID" select="AssetID"/>

<xsl:element name="AssetTotal">

<xsl:value-of select="AssetPercentage div 100 * ../../Assets/Miscellaneous/Value[../AssetID=$AssID]"/>

</xsl:element>

</xsl:for-each>

[i didn't add the FileMaker stuff. The METADATA field is "AssetTotal." And you'd need the requisite <COL><DATA> tags.

Also I'm using "<xsl:for-each>", whereas you might be using separate templates.]

Like I said, I haven't done this math operation before. Also, I just paste the xml code in, it doesn't seem to care about the tags. I believe I have html turned off in my preferences (if there is such).

[Fenton]

I'm not sure what exactly you want to do. I mean, you could just import:

Document/Transaction/Client/Matter/Assets/Miscellaneous/Value

again, with your 2nd XSL, into your Assets table, then do the math in FileMaker.

It would mean an extra field, but so what?

You could alternatively do the math in your 2nd XSL, by adding an element for the total, and importing that:

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest/AssetPercentage">

<xsl:element name="AssetTotal">

<xsl:value-of select=". div 100 *../../../Assets/Miscellaneous/Value"/>

</xsl:element>

</xsl:for-each>

I've not done this before, but the above appears to work. This is assuming there is only 1 of them in each, which is probably not a safe assumption. It would be better to check the AssetID, which is in either:

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

<xsl:variable name="AssID" select="AssetID"/>

<xsl:element name="AssetTotal">

<xsl:value-of select="AssetPercentage div 100 * ../../Assets/Miscellaneous/Value[../AssetID=$AssID]"/>

</xsl:element>

</xsl:for-each>

[i didn't add the FileMaker stuff. The METADATA field is "AssetTotal." And you'd need the requisite <COL><DATA> tags.

Also I'm using "<xsl:for-each>", whereas you might be using separate templates.]

Like I said, I haven't done this math operation before. Also, I just paste the xml code in, it doesn't seem to care about the tags. I believe I have html turned off in my preferences (if there is such).

[QuinTech]

This is assuming there is only 1 of them in each

Right. I should have specified that the source XML is much more extensive, so ../../../Assets/Miscellaneous/Value will not work if the desired Miscellaneous element is not the first element under the Assets element.

The reason i'd prefer not to do the math in FMP is because the logic starts to push the limits of my brain. There is a whole lot of other stuff going on that i haven't included in the issue because it's not quite relevant; i'm using 5 XSLTs, 5 FMP files, and maybe 10 scripts to do all the processing necessary. I'd like to get this part out of the way using XSLT for that reason.

It would be better to check the AssetID

So you think looping through each asset till i find the right one is the best idea? I was shying away from that, but that's partly because the syntax you've used above with the xsl:variable syntax is new to me. That looks a whole lot cleaner than what i would have come up with. Conceptually, it looks like it is the right idea; let me try to implement it and i'll see if it works.

Fenton, thanks a ton, once again.

J

[QuinTech]

This is assuming there is only 1 of them in each

Right. I should have specified that the source XML is much more extensive, so ../../../Assets/Miscellaneous/Value will not work if the desired Miscellaneous element is not the first element under the Assets element.

The reason i'd prefer not to do the math in FMP is because the logic starts to push the limits of my brain. There is a whole lot of other stuff going on that i haven't included in the issue because it's not quite relevant; i'm using 5 XSLTs, 5 FMP files, and maybe 10 scripts to do all the processing necessary. I'd like to get this part out of the way using XSLT for that reason.

It would be better to check the AssetID

So you think looping through each asset till i find the right one is the best idea? I was shying away from that, but that's partly because the syntax you've used above with the xsl:variable syntax is new to me. That looks a whole lot cleaner than what i would have come up with. Conceptually, it looks like it is the right idea; let me try to implement it and i'll see if it works.

Fenton, thanks a ton, once again.

J

[QuinTech]

This is assuming there is only 1 of them in each

Right. I should have specified that the source XML is much more extensive, so ../../../Assets/Miscellaneous/Value will not work if the desired Miscellaneous element is not the first element under the Assets element.

The reason i'd prefer not to do the math in FMP is because the logic starts to push the limits of my brain. There is a whole lot of other stuff going on that i haven't included in the issue because it's not quite relevant; i'm using 5 XSLTs, 5 FMP files, and maybe 10 scripts to do all the processing necessary. I'd like to get this part out of the way using XSLT for that reason.

It would be better to check the AssetID

So you think looping through each asset till i find the right one is the best idea? I was shying away from that, but that's partly because the syntax you've used above with the xsl:variable syntax is new to me. That looks a whole lot cleaner than what i would have come up with. Conceptually, it looks like it is the right idea; let me try to implement it and i'll see if it works.

Fenton, thanks a ton, once again.

J

[QuinTech]

<?xml version="1.0"?>

<Document>

  <Transaction>

    <Client>

      <Matter>

        <Assets>

          <Miscellaneous>

            <AssetID>35</AssetID>

            <Value>56000</Value>

          </Miscellaneous>

        </Assets>

        <Bequests>

          <Bequest>

            <AssetPercentage>75</AssetPercentage>

            <AssetID>35</AssetID>

          </Bequest>

        </Bequests>

      </Matter>

    </Client>

  </Transaction>

</Document>

Do you see this with all XML tags? If so, that indicates i have a display issue rather than a posting issue.

J

[QuinTech]

<?xml version="1.0"?>

<Document>

  <Transaction>

    <Client>

      <Matter>

        <Assets>

          <Miscellaneous>

            <AssetID>35</AssetID>

            <Value>56000</Value>

          </Miscellaneous>

        </Assets>

        <Bequests>

          <Bequest>

            <AssetPercentage>75</AssetPercentage>

            <AssetID>35</AssetID>

          </Bequest>

        </Bequests>

      </Matter>

    </Client>

  </Transaction>

</Document>

Do you see this with all XML tags? If so, that indicates i have a display issue rather than a posting issue.

J

[QuinTech]

<?xml version="1.0"?>

<Document>

  <Transaction>

    <Client>

      <Matter>

        <Assets>

          <Miscellaneous>

            <AssetID>35</AssetID>

            <Value>56000</Value>

          </Miscellaneous>

        </Assets>

        <Bequests>

          <Bequest>

            <AssetPercentage>75</AssetPercentage>

            <AssetID>35</AssetID>

          </Bequest>

        </Bequests>

      </Matter>

    </Client>

  </Transaction>

</Document>

Do you see this with all XML tags? If so, that indicates i have a display issue rather than a posting issue.

J

[Martin Brändle]

I complained also once. You have to use &lt; for every < . And &amp;amp;lt; for every &lt;. And &amp;amp;&amp;amp;lt; for every &amp;amp;lt;. And ...

Martin

[Martin Brändle]

I complained also once. You have to use &lt; for every < . And &amp;amp;lt; for every &lt;. And &amp;amp;&amp;amp;lt; for every &amp;amp;lt;. And ...

Martin

[Martin Brändle]

I complained also once. You have to use &lt; for every < . And &amp;amp;lt; for every &lt;. And &amp;amp;&amp;amp;lt; for every &amp;amp;lt;. And ...

Martin

[QuinTech]

<Tag>

<Tag>

<Tag>

<Tag>

Well, i edited my earlier post and it didn't work, but here it does. Whatever. Thanks for the tip, Martin.

J

[QuinTech]

<Tag>

<Tag>

<Tag>

<Tag>

Well, i edited my earlier post and it didn't work, but here it does. Whatever. Thanks for the tip, Martin.

J

[QuinTech]

<Tag>

<Tag>

<Tag>

<Tag>

Well, i edited my earlier post and it didn't work, but here it does. Whatever. Thanks for the tip, Martin.

J

[QuinTech]

lol

[QuinTech]

lol

[QuinTech]

lol

[Fenton]

So you think looping through each asset till i find the right one is the best idea? I was shying away from that, but that's partly because the syntax you've used above with the xsl:variable syntax is new to me.

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

[Fenton]

So you think looping through each asset till i find the right one is the best idea? I was shying away from that, but that's partly because the syntax you've used above with the xsl:variable syntax is new to me.

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

[Fenton]

So you think looping through each asset till i find the right one is the best idea? I was shying away from that, but that's partly because the syntax you've used above with the xsl:variable syntax is new to me.

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

[QuinTech]

That did the trick! I was a little sloppy in my use of the word "looping" earlier... i guess the XSLT is not looping as far as we can see, though i imagine it does have to loop through elements until it finds what it is looking for. In any case, i can see how this would be a very convenient operator to avoid the whole <xsl:for-each/> loop process.

(My initial thought was to use another for-each loop, which would have been the fourth nested for-each loop, and that was starting to make me squeamish. It just seems like inefficient design.)

Oddly enough, I don't have to use & lt; for <. I don't know why, but I'm glad.

You should be glad! Another Mac side-effect, perhaps?

[QuinTech]

That did the trick! I was a little sloppy in my use of the word "looping" earlier... i guess the XSLT is not looping as far as we can see, though i imagine it does have to loop through elements until it finds what it is looking for. In any case, i can see how this would be a very convenient operator to avoid the whole <xsl:for-each/> loop process.

(My initial thought was to use another for-each loop, which would have been the fourth nested for-each loop, and that was starting to make me squeamish. It just seems like inefficient design.)

Oddly enough, I don't have to use & lt; for <. I don't know why, but I'm glad.

You should be glad! Another Mac side-effect, perhaps?

[QuinTech]

That did the trick! I was a little sloppy in my use of the word "looping" earlier... i guess the XSLT is not looping as far as we can see, though i imagine it does have to loop through elements until it finds what it is looking for. In any case, i can see how this would be a very convenient operator to avoid the whole <xsl:for-each/> loop process.

(My initial thought was to use another for-each loop, which would have been the fourth nested for-each loop, and that was starting to make me squeamish. It just seems like inefficient design.)

Oddly enough, I don't have to use & lt; for <. I don't know why, but I'm glad.

You should be glad! Another Mac side-effect, perhaps?

[Martin Brändle]

No, not a Mac side-effect, I use also a Mac. I think it's like Fenton hinted before: Avoid UBBCode and HTML when posting. < . Aha. This was not a &lt;. Sorry for mixing something else into this thread - Fenton's analysis of your XML was really nice.

[Martin Brändle]

No, not a Mac side-effect, I use also a Mac. I think it's like Fenton hinted before: Avoid UBBCode and HTML when posting. < . Aha. This was not a &lt;. Sorry for mixing something else into this thread - Fenton's analysis of your XML was really nice.

[Martin Brändle]

No, not a Mac side-effect, I use also a Mac. I think it's like Fenton hinted before: Avoid UBBCode and HTML when posting. < . Aha. This was not a &lt;. Sorry for mixing something else into this thread - Fenton's analysis of your XML was really nice.

[Fenton]

Nice new hat QuinTech :-]

It's difficult for we FileMaker developers to understand the "template" like mechanism of XSL. Some of what we think would require an explicit loop is already part of its matching ability. It procedes in a linear manner, with its "<xsl:template>" and "<xsl:for-each>" tags, but can also test against or get data anywhere else in the document. It can also put the same data twice, only get some data, and even add data.

The test syntax, [this here=that there, or some other condition] or, in our case above, [that there=this here], can be all kinds of things. The trick is to be able to specify what/where in the hierarchy you want to test against.

The variable was created specifically because when you're "that there" you're no longer "this here," so you need to capture "this here" first (just like setting a global) before you go. You can alternatively use the "current()" function, but that's messier.

If what's in the brackets is a number, or evaluates to a number, instead of being a test, then it specifies the position at which to get data. We could also have solved the problem that way. But that would assume that there was exact symmetry between the Assets and Bequests. Maybe there is?

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

<xsl:variable name="pos" select="position()"/>

<xsl:element name="AssetTotal">

<xsl:value-of select="AssetPercentage div 100 * ../../Assets/Miscellaneous[$pos]/Value"/>

</xsl:element>

</xsl:for-each>

[Martin, thanks for the compliment. I think I explain things pretty well, sometimes more than I actually know. In that case, I rely on more knowledgeable folks like yourself to correct me :-]

[Fenton]

Nice new hat QuinTech :-]

It's difficult for we FileMaker developers to understand the "template" like mechanism of XSL. Some of what we think would require an explicit loop is already part of its matching ability. It procedes in a linear manner, with its "<xsl:template>" and "<xsl:for-each>" tags, but can also test against or get data anywhere else in the document. It can also put the same data twice, only get some data, and even add data.

The test syntax, [this here=that there, or some other condition] or, in our case above, [that there=this here], can be all kinds of things. The trick is to be able to specify what/where in the hierarchy you want to test against.

The variable was created specifically because when you're "that there" you're no longer "this here," so you need to capture "this here" first (just like setting a global) before you go. You can alternatively use the "current()" function, but that's messier.

If what's in the brackets is a number, or evaluates to a number, instead of being a test, then it specifies the position at which to get data. We could also have solved the problem that way. But that would assume that there was exact symmetry between the Assets and Bequests. Maybe there is?

<xsl:for-each select="Document/Transaction/Client/Matter/Bequests/Bequest">

<xsl:variable name="pos" select="position()"/>

<xsl:element name="AssetTotal">

<xsl:value-of select="AssetPercentage div 100 * ../../Assets/Miscellaneous[$pos]/Value"/>

</xsl:element>

</xsl:for-each>

[Martin, thanks for the compliment. I think I explain things pretty well, sometimes more than I actually know. In that case, I rely on more knowledgeable folks like yourself to correct me :-]