Hi, i have attached an xslt and sample xml. The xml file has two <recovery> elements and, when i try to import it using the xslt, i get a parsing error at the beginning of the second <recovery> element. If i remove the second <recovery>, leaving only one element, the import works.

For the life of me i can't figure out why this xslt won't work for more than one element. Can anyone help me?

TIA,

Jerry

xmlsample.zip

It's because there can be only 1 root element in a valid XML file.* In order for it to work you'd just need to enclose all the elements with another, even if you have to make it up.

<recoveries>

<recovery date="20050207" time="14_30_44" firmName="firm1" firmPhone="412 5551212">

<recoveredFile>Transactusr</recoveredFile>

<recoveredFile>Xxausr</recoveredFile>

</recovery>

<recovery date="20050208" time="9_06_15" firmName="firm2" firmPhone="412 5551213">

<recoveredFile>ZTranShlusr</recoveredFile>

</recovery>

</recoveries>

Then, in the XSL, also include the root above, as in:

<xsl:for-each select="recoveries/recovery">

* I think, and my XML program agrees. It selects the 2nd <recovery> element and says:

Error on line 6 of your XML code:

XML parser error 9: junk after document element

There's also something funny with the count in the Metadata; it's not evaluating at all. I don't know that it's needed anyway. You can just say:

Found=""

But it should work; maybe we'll figure it out someday.

Thanks, Fenton. I figured it would be you that pulled through. I had actually just figured out that it would work if i enclosed it inside another element, but had no idea why; thanks for filling me in on the 1-root-element limitation. I'll go back and re-design the original XML export. I have so much theory to learn!

Thanks,

J

There's also something funny with the count in the Metadata; it's not evaluating at all.

How did you know this? Like you said, it doesn't seem to matter, but i can't find any place to look at the metadata and think it's something i should learn.

To look at the result you need a program that can transform XML with an XSL stylesheet and show you the result. There are several, especially on PCs; but I don't know what they are.

There's really only one free one on Macs, TestXSLT, which is, in some ways, somewhat basic (no syntax coloring), but in others, such as error reporting and HTML rendering, quite advanced.

You can just export from FileMaker, with no stylesheet, to see what XML export looks like. But for any troubleshooting (required), a real xml editor/rendering engine is really useful.

It's odd about that count() function in the Metadata. I have examples from the FileMaker site which have the same structure. But it is simply not evaluating for me.

XMLSpy from Altova is such a product which has a XML editor and a built-in XSLT engine, but is quite expensive. You can get a 30-day evaluation license at the URL above.

Or get the free Saxon XSLT engine from Michael Kay. I used it once to transform a large FileMaker XML output to some strange output and also to debug the XML code. Was without problems.

Martin

Thanks for the tip, Martin. XMLSpy looks like a real Rolls-Royce app, but maybe outside our budget. I will definitely check out Saxon, though. Funny how when i searched sourceforge for "xml editor" yesterday that did not turn up. Admittedly, that was probably not the best choice of search terms, but you'd think it would be a common criteria to search on.

J

Saxon is not an editor, it's just a plain transformation engine. By googling a little bit on "free XML editors", I find these pages:

XML editors list

Jaxe on sourceforge

Martin

Thanks, Martin. I've done a little homework, and come up with a few that have (i think) everything i need: XMLSpy, Oxygen, and XmlShell by softgauge.com. The first two i'd heard of, XmlShell is new to me. Saxon and Jaxe look a bit too complicated-- maybe i can use those once i take the training wheels off. Have you ever heard of or used XmlShell, and do you have an opinion on it?

Also, XmlShell offers the capability to edit, validate, and transform XML; is there anything else the typical programmer would need to do? The interface isn't that big a deal for me; i think i could work through a bad interface, although XmlShell's seems pretty nice.

Thanks again for all your input.

J

Thanks for your tip, QuinTech. I use XMLSpy, but will have a look at XmlShell and report back. Oxygen looks nice and is Java based, so that one can use it on various platforms. However, I don't know the performance.

Martin

Tried XmlShell out: Small, fast, easy to use, cheap, has the most necessary functions, adds the end tags, has a library of html and xsl tags, but not all attributes are given with a tag, and attributes are not automatically expanded with ="" (very handy in XMLSpy). As XSLT engine the MSXML parser is used - you should select version 3 or 4 to be XSLT 1.0 compliant.

As you said: XMLSpy is the Rolls-Royce (or MS Office), XmlShell the Mini (or WordPad) - both can be used to drive.

Martin

Thanks a ton, Martin and Fenton. Since my XML work will probably be limited and XmlShell is inexpensive, i think i will go with that it. I'm sure i will appreciate the features (or the lack thereof) you describe more as time goes on. And since i bet people will search for it in the future, some search terms:

Windows XML editor

Windows XML parser

Windows XML transformer

Windows XML transformation

Windows XML engine

Windows XML rendering engine

Windows XML renderer

Windows XSLT editor

Windows XSLT parser

Windows XSLT transformer

Windows XSLT transformation

Windows XSLT engine

Windows XSLT rendering engine

Windows XSLT renderer

Anything else i should add?

Thanks for the great info. Just an update on Alto XMLSpy. The currently offer a free home edition. It has some of the more advanced features stripped out, but the price is right.