Importing Google Calendar Data

[TRF]

So close...

I'm able to create and update google calendar items. I'm now attempting to import calendar events from a date range. I can actually get the data in xml format but I'm now having difficulty with my xsl. Filemaker keeps choking on the google tags with "

Error:

"Unable to resolve prefix 'gd'.

patter = 'gd:comments'(G_Cal_to_FM.xsl, 56,52)

Remaining tokens: ()

xsl=G_Cal_to_FM.xsl

<?xml version="1.0" encoding="utf-8" ?>

0

Sample Node:

http://www.google.com/calendar/feeds/default/private/full/x

2007-07-09T20:00:07.000Z

2007-07-09T20:00:10.000Z

Title

Me

[email protected]

[Mikhail Edoshin]

gd is a namespace prefix. Namespace declaration is like that:

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

Try to find what declaration Google Data uses in its file and declare that xmlns:gd="(that declaration)" in your xsl:stylesheet element..

[Fenton]

It would be better if you zipped the xml and xsl files and uploaded them. They get fairly messed up if you load the text directly here; OK for small stuff, but a pain for this. Also, the fragment of xml is missing its namespaces, which are at the top. So I can only guess what they are. Fortunately, they are really only placeholders in xml/xsl. It does not really try to resolve them. So I just used what was in the file; more or less made them up.

So there were missing namespaces in the xml posted, which were likely in the full xml file. However there were NO namespaces declared to match those in the xsl. That's why the errors for "gd:"; and you would have gotten one for "gCal:" also (if you got that far).

So I declared them in the xsl; then I excluded them from the FileMaker result. FileMaker has no use for "gd:" and "gCal:" namespaces, so you declare them to "get" the data, then exclude them from the result. It makes sense if you think of it as a 2-step process.

A lot of your "fields" were referencing elements with no real content of their own. The data was further in, in an attribute. Yet you have fields for the element and the attribute; ie., too many fields. So I deleted a few.

[moved attachment down a couple posts]

Edited July 10, 2007 by Guest
moved file to later post

[TRF]

Beautiful! Thanks. One thing - I munged my original xsl by not including "Found" in

I'm using curl (this is an os x only solution) to work with googles API - this was the last step to completing my solution.

[Fenton]

Oops. And I didn't actually import into FileMaker to test. I was just using an xslt editor to view the data (TestXSLT). So here's a fixed file.

G_Cal_xml.zip

[TRF]

OK so I didn't do adequate testing either. I tweaked your xsl a bit and got the import dialog to come up quickly and easily - but it imported 0 records. I figured this was likely because the real root of the xml document is - which I had not accounted for. So I applied the template match to /feed instead of /. Now I'm getting an error for improperly formatted xml. I checked my syntax and the document looks good. Is this a name space issue?

Sample3.txt

G_Cal._xsl.txt

[Fenton]

Yep, you'se got some namespaces there. I guess the bigger the company, the more namespaces they use. Fortunately, you can just copy/paste them into the tag of your xsl. Whether you need them all depends on a couple things.

First, look to see if they actually assigned them to the root element, is the root element followed by namespaces. If it is, it means they are effectively prefixing every element within, other than those that have a specific namespace prefix themselves. In other words, it's an implicit namespace; it is not explicitly shown in the xml.

FileMaker does this themselves (so we can't complain).

Your job, as xsl stylesheet creator, is to make up an explicit prefix tag, declare it in the element, assigning it to that implicit namespace. Example:

xmlns:fm="http://www.filemaker.com/fmpxmlresult"

Then, if you wanted to extract a FileMaker element, you'd have to do it like this:

It may seem weird, but it is fundamental to the "extensible" meaning of xml/xsl. It allows people to tag their terms, so they don't collide with others; if say someone else has a of theater seats. You have to write your xsl respecting their namespaces.

In this case we've got several namespaces from Google. The 1st one in the list is implicit in the data, ie., it has no explicit prefix:

This means that every element below can only be selected via that namespace.

But it has no prefix. So, in the xsl, I made one up.

xmlns:ggl='http://www.w3.org/2005/Atom'

The ROW selector then looks like this:

You do not have to prefix attributes (@something), because they are referenced by their element.

For FileMaker import, you include all the prefixes declared in:

exclude-result-prefixes="ggl gd gCal openSearch">

Though I didn't even use gCal or openSearch; but you might.

Clear as mud?

G_Cal.xsl.zip

[TRF]

Makes sense - and it makes sense that google would have an abundance of namespaces to deal with! thanks again.

[TRF]

Back again! importing google data into my filemaker solution now - but having difficulty importing multiple lines. Each tag has a attribute which distinguishes it (example below). Do I need to create an attribute for this? Original xsl at the bottom.

XSL-

<?xml version="1.0" encoding="utf-8" ?>

xmlns:ggl='http://www.w3.org/2005/Atom'

xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/'

xmlns:gCal='http://schemas.google.com/gCal/2005'

xmlns:gd='http://schemas.google.com/g/2005'

exclude-result-prefixes="ggl gd gCal openSearch">

0

[Fenton]

You could pick them out, and put them in separate fields, using a test on the "rel" attribute.

Also, the variable can be assigned in one line, one element.

[TRF]

That did it -

I had attempted this but ran into syntax issues. Don't suppose you have a favorite reference for proper use of "[" and "@" ?

Thanks again!