Invalid XML generated by the API?

User Support Data Management
, , ,
1

I’ve been trying to get some data out of Kobo through the API and (besides some other problems), it seem that the API is generating invalid XML?

The URL I’m using the access the data is this: https://kc.humanitarianresponse.info/api/v1/data/67602?format=xml

I’ve completed some surveys through the web interface with the same form and when I now look at the XML from the API, I see that the XML tags contain the (repeat) group and the “field” name, seperated by a slash e.g.

<group1/dataA>Some data</group1/dataA>

However, when I try to use this XML, the XML parser seems not to like the slash in the middle of the tagname.

I’ve tried to view the XML in Chrome and imported it through the XML parser of VBA and both indicate at exactly the first slash in the middle of an opening tag of a field in my first group of data, giving the error “error on line 2 at column 32: error parsing attribute name”

Doing a simple search & replace before using the XML is also not working as the slash is used in the closing tag.

So, I understand that kobo is using this format to make sure that all tags are unique within the form and that is great, but it seems to me that a different separator character should be used which fits the same purpose but will not cause the XML to be considered invalid by e.g. Chrome (which I guess anyone will agree is not an obscure barely used app)

I’ve tried some other separators like ~, $, # which Chrome didn’t seem to like either, however, the period “.” seems to work fine and from a technical perspective, the period would work very well to to describe a group name and field within the group.

I hope you agree that this could be considered a small bug that could easily be fixed in an upcoming update?

Thanks, Gerard

2

Hi Gerard,
This is indeed a bug and we’re aware of it. This only affects the XML generated through the kobocat API, while the regular XML provided to Collect and Enketo is correct.

The new version of our kpi repository contains an XML endpoint that you can use for this purpose, which outputs properly formatted XML. This issue is a legacy problem we inherited from formhub; you can find open issues related to kobocat at http://github.org/kobotoolbox/kobocat.

Best,
Tino

···

On Sun, May 22, 2016 at 11:08 PM Gerard Schut gerard...@gmail.com wrote:

I’ve been trying to get some data out of Kobo through the API and (besides some other problems), it seem that the API is generating invalid XML?

The URL I’m using the access the data is this: https://kc.humanitarianresponse.info/api/v1/data/67602?format=xml

I’ve completed some surveys through the web interface with the same form and when I now look at the XML from the API, I see that the XML tags contain the (repeat) group and the “field” name, seperated by a slash e.g.

<group1/dataA>Some data</group1/dataA>

However, when I try to use this XML, the XML parser seems not to like the slash in the middle of the tagname.

I’ve tried to view the XML in Chrome and imported it through the XML parser of VBA and both indicate at exactly the first slash in the middle of an opening tag of a field in my first group of data, giving the error “error on line 2 at column 32: error parsing attribute name”

Doing a simple search & replace before using the XML is also not working as the slash is used in the closing tag.

So, I understand that kobo is using this format to make sure that all tags are unique within the form and that is great, but it seems to me that a different separator character should be used which fits the same purpose but will not cause the XML to be considered invalid by e.g. Chrome (which I guess anyone will agree is not an obscure barely used app)

I’ve tried some other separators like ~, $, # which Chrome didn’t seem to like either, however, the period “.” seems to work fine and from a technical perspective, the period would work very well to to describe a group name and field within the group.

I hope you agree that this could be considered a small bug that could easily be fixed in an upcoming update?

Thanks, Gerard

–

You received this message because you are subscribed to the Google Groups “Kobo Users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to kobo-users+...@googlegroups.com.

To post to this group, send email to kobo-...@googlegroups.com.

Visit this group at https://groups.google.com/group/kobo-users.

For more options, visit https://groups.google.com/d/optout.

3

Hi Tino,

Thanks for the reply. It’s good to hear it’s a know problem and there is a solution.

I’m sure you’re very busy, but your reply was a bit short. You mention “our kpi repository”. I did a bit of searching and found it on github, but I don’t quite understand how to use it. How can I access the data on kc.humanitarianresponse.info with/through pki?

Or do I need to set up my own server for it? I don’t mind learning new things, but this one was a bit too cryptic for me to work out.

Hopefully, you can spare me a few more minutes and explain it in a bit more detail or a link where I can read about using this new endpoint.

Thanks in advance, Gerard

···

On Monday, 23 May 2016 21:03:55 UTC+1, Tino Kreutzer wrote:

Hi Gerard,
This is indeed a bug and we’re aware of it. This only affects the XML generated through the kobocat API, while the regular XML provided to Collect and Enketo is correct.

The new version of our kpi repository contains an XML endpoint that you can use for this purpose, which outputs properly formatted XML. This issue is a legacy problem we inherited from formhub; you can find open issues related to kobocat at http://github.org/kobotoolbox/kobocat.

Best,
Tino
On Sun, May 22, 2016 at 11:08 PM Gerard Schut gera...@gmail.com wrote:

I’ve been trying to get some data out of Kobo through the API and (besides some other problems), it seem that the API is generating invalid XML?

The URL I’m using the access the data is this: https://kc.humanitarianresponse.info/api/v1/data/67602?format=xml

I’ve completed some surveys through the web interface with the same form and when I now look at the XML from the API, I see that the XML tags contain the (repeat) group and the “field” name, seperated by a slash e.g.

<group1/dataA>Some data</group1/dataA>

However, when I try to use this XML, the XML parser seems not to like the slash in the middle of the tagname.

I’ve tried to view the XML in Chrome and imported it through the XML parser of VBA and both indicate at exactly the first slash in the middle of an opening tag of a field in my first group of data, giving the error “error on line 2 at column 32: error parsing attribute name”

Doing a simple search & replace before using the XML is also not working as the slash is used in the closing tag.

So, I understand that kobo is using this format to make sure that all tags are unique within the form and that is great, but it seems to me that a different separator character should be used which fits the same purpose but will not cause the XML to be considered invalid by e.g. Chrome (which I guess anyone will agree is not an obscure barely used app)

I’ve tried some other separators like ~, $, # which Chrome didn’t seem to like either, however, the period “.” seems to work fine and from a technical perspective, the period would work very well to to describe a group name and field within the group.

I hope you agree that this could be considered a small bug that could easily be fixed in an upcoming update?

Thanks, Gerard

–

You received this message because you are subscribed to the Google Groups “Kobo Users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to kobo-users+...@googlegroups.com.

To post to this group, send email to kobo...@googlegroups.com.

Visit this group at https://groups.google.com/group/kobo-users.

For more options, visit https://groups.google.com/d/optout.

4

Hi Gerard,

The repository for KPI, which is the code behind the library, formbuilder, and soon the overall user interface for deployed projects, is located at https://github.com/kobotoolbox/kpi. You don’t need to install it or look at the source code to use the XML. KPI us the default tool used by all new users created in 2016 and all existing users who have opted in to the Beta version already.

To download the XML version of any of your forms (assuming you are using the new version), visit http://kobo.humanitarianresponse.info/forms/#/forms, select a project, click the ‘view’ button to open the project, then click the three dots next to the version list to get to the download XML option. Note the URL for this download, which is https://kobo.humanitarianresponse.info/forms/assets/{pk}.xml

Inline image 1
Inline image 1848×349 40.2 KB

Best,

Tino

···

On Tue, May 24, 2016 at 3:58 PM, Gerard Schut gerard...@gmail.com wrote:

Hi Tino,

Thanks for the reply. It’s good to hear it’s a know problem and there is a solution.

I’m sure you’re very busy, but your reply was a bit short. You mention “our kpi repository”. I did a bit of searching and found it on github, but I don’t quite understand how to use it. How can I access the data on kc.humanitarianresponse.info with/through pki?

Or do I need to set up my own server for it? I don’t mind learning new things, but this one was a bit too cryptic for me to work out.

Hopefully, you can spare me a few more minutes and explain it in a bit more detail or a link where I can read about using this new endpoint.

Thanks in advance, Gerard

On Monday, 23 May 2016 21:03:55 UTC+1, Tino Kreutzer wrote:

Hi Gerard,
This is indeed a bug and we’re aware of it. This only affects the XML generated through the kobocat API, while the regular XML provided to Collect and Enketo is correct.

The new version of our kpi repository contains an XML endpoint that you can use for this purpose, which outputs properly formatted XML. This issue is a legacy problem we inherited from formhub; you can find open issues related to kobocat at http://github.org/kobotoolbox/kobocat.

Best,
Tino
On Sun, May 22, 2016 at 11:08 PM Gerard Schut gera...@gmail.com wrote:

I’ve been trying to get some data out of Kobo through the API and (besides some other problems), it seem that the API is generating invalid XML?

The URL I’m using the access the data is this: https://kc.humanitarianresponse.info/api/v1/data/67602?format=xml

I’ve completed some surveys through the web interface with the same form and when I now look at the XML from the API, I see that the XML tags contain the (repeat) group and the “field” name, seperated by a slash e.g.

<group1/dataA>Some data</group1/dataA>

However, when I try to use this XML, the XML parser seems not to like the slash in the middle of the tagname.

I’ve tried to view the XML in Chrome and imported it through the XML parser of VBA and both indicate at exactly the first slash in the middle of an opening tag of a field in my first group of data, giving the error “error on line 2 at column 32: error parsing attribute name”

Doing a simple search & replace before using the XML is also not working as the slash is used in the closing tag.

So, I understand that kobo is using this format to make sure that all tags are unique within the form and that is great, but it seems to me that a different separator character should be used which fits the same purpose but will not cause the XML to be considered invalid by e.g. Chrome (which I guess anyone will agree is not an obscure barely used app)

I’ve tried some other separators like ~, $, # which Chrome didn’t seem to like either, however, the period “.” seems to work fine and from a technical perspective, the period would work very well to to describe a group name and field within the group.

I hope you agree that this could be considered a small bug that could easily be fixed in an upcoming update?

Thanks, Gerard

–

You received this message because you are subscribed to the Google Groups “Kobo Users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to kobo-us...@googlegroups.com.

To post to this group, send email to kobo...@googlegroups.com.

Visit this group at https://groups.google.com/group/kobo-users.

For more options, visit https://groups.google.com/d/optout.

–

You received this message because you are subscribed to the Google Groups “Kobo Users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to kobo-users+...@googlegroups.com.

To post to this group, send email to kobo-...@googlegroups.com.

Visit this group at https://groups.google.com/group/kobo-users.

For more options, visit https://groups.google.com/d/optout.