search

getodk / xforms-spec

The XForms-derived specification used in the ODK ecosystem. If you are interested in building a tool that is compliant with the forms rendered by ODK tools, this is the place to start. ✨⚒✨
https://getodk.github.io/xforms-spec/
30 stars 26 forks source link

Removed word binary and added CSV resource, closes #214 #244

Closed MartijnR closed 4 years ago

MartijnR commented 5 years ago

I was getting confused about the distinction between Virtual and File, and I added some text about that. Let me know if that's not how you see it though!

lognaturel commented 5 years ago

I agree that this part of the spec is confusing.

I love everything about this except, as I'm guessing you anticipated, "published in an XForms manifest whose location the client is aware of."

I don't think it's strictly necessary that the files be in a form list manifest (though certainly they should generally be). Also, this spec doesn't go into any OpenRosa details so without context, I don't think it's clear what "manifest" refers to, right?

This is a slightly more involved change but how about focusing on the custom schemes rather than on the endpoints? That is, the two sections would be "file type schemes" and "virtual schemes". For file type schemes, I'm imagining an explanation like "File type schemes allow implementations of this specification to choose how and where they store files of different types used as form media. It is up to clients to resolve URIs prefixed by one of the valid schemes to a file."

Is it the case that "virtual" schemes will always refer to an XML resource? I think so? Where jr://file is essentially a path prefix, jr://last-saved refers directly to a (dynamically generated) resource and I presume all "virtual" schemes would operate this way as well. So I don't even know if calling them "endpoints" makes sense.

MartijnR commented 4 years ago

Thanks! Sorry, I had to think about this for a few months.

I agree to leave out reference to manifest, and have done so in an added commit.

I don't think differentiating schemes is the way to go, since I believer on the jr part of the URI is the scheme (and it's the same).

I'm also not sure if the word "endpoint" is the best, but I think it's correct terminology here.

Yes, for now the virtual endpoints are XML, so I think we can leave that until that changes.