Jump to content
Sign in to follow this  
Jaren Meier

XML Import Question

Recommended Posts

Stupid question: I am getting the following error when trying to import the XML attached lower in the message. I am real new to this and this is a project I am helping someone else on. I am not using any XSL style sheet on the import.

------------------------------------

XML parsing error:

Atribute 'regionalmanagername' is not

declared for element 'region'

Line Number: 2

Column Number: 130056

-------------------------------------

<?xml version="1.0" encoding="iso-8859-1" ?>

-

-

-

- Westboro Motors, Inc.</p><p>

-

- 271 Turnpike Rd. Rte. 9</p><p>

-

- www.westboromotors.com</p><p>

-

- WESMMA</p><p>

-

-

- James Tonelli</p><p>

-

- charlestonelli@westborotoyota.com</p><p>

-

-

-

- James Tonelli</p><p>

-

- charlestonelli@westborotoyota.com</p><p>

-

-

- James Tonelli</p><p>

-

- charlestonelli@westborotoyota.com</p><p>

-

Share this post


Link to post
Share on other sites

Short answer: You can't import xml into FileMaker without an xsl stylesheet, not unless it was xml exported by FileMaker in the first place (in FMPXMLRESULT grammar).

Longer answer: There are actually 3 levels of data in the xml you posted; it must be 3 because at least the 2 lower levels could have a variable number of records:

Dealer

Program

Club

To import those into FileMaker you would need 3 tables. That is not an xml requirement; it would be the same for importing from another FileMaker file.

So, you need 3 xml imports, 3 xsl stylesheets; all import from the same xml file, they just pick different pieces out of it, to put in the respective FileMaker table. The lower level imports need to "reach up" and get at least the ID field of their parent; otherwise you'd have trouble relating them. I do not know for sure whether the id's in the xml file are really unique. We'll assume so (for now).

Dealers_xml.zip

Share this post


Link to post
Share on other sites

P.S. The normalize-space(.) function was used to strip out the extra returns, which were otherwise inserted by the CDATA tags. You could also just do this later inside FileMaker, with an auto-enter calculation, with Replace. But that's clunky also. If someone knows a better way, please do tell :-]

Share this post


Link to post
Share on other sites

As far as I know normalize-space() removes only empty text nodes. It won't trim whitespace characters from begin and end of a value. This can be done in FM or in XSLT itself with an utility function.

Share this post


Link to post
Share on other sites

Quote from http://www.w3.org/TR/xpath, the XPath 1.0 standard:

"The normalize-space function returns the argument string with whitespace normalized by stripping leading and trailing whitespace and replacing sequences of whitespace characters by a single space. Whitespace characters are the same as those allowed by the S production in XML. If the argument is omitted, it defaults to the context node converted to a string, in other words the string-value of the context node."

Share this post


Link to post
Share on other sites

The xsl element that strips empty nodes is , a top level element.

http://www.w3schools.com/xsl/el_preserve-space.asp

I usually just remove extra leading whitespace within FileMaker, using an auto-enter calculation, using a Custom Function (there's several that do this with various levels of completeness). But in this case it was so pervasive.

What I said earlier was not really correct however:

"The normalize-space(.) function was used to strip out the extra returns, which were otherwise inserted by the CDATA tags."

It was not created by the CDATA tags per se. It was because in the posted XML they were on their own line. If you put them (and their end tag) on the same line as their parent element (name, address, etc.), then you do not get the extra returns; hence do not really need the normalize-space() function. Except the (sloppy, IMHO) creators of this xml put leading spaces inside the CDATA tags also, so normalize-space() still helps.

The original "xml" posted was not really xml. It was copy/pasted from Internet Explorer, which added the dashes (which are actually "folding" widgets), and, quite likely added the extra lines, as it is an xml parser app (Safari isn't).

I'd recommend that the poster get a real xml/xsl application, or at least text editor; there's good free ones, on both platforms. It's also most useful if the poster of a question regarding downloadable xml can post a link to request the xml, so we can just go get it ourselves. But that's often not possible.

Edited by Guest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.