Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions around <http:response/> #10

Closed
ChristianGruen opened this issue Oct 30, 2012 · 8 comments · Fixed by #35
Closed

Questions around <http:response/> #10

ChristianGruen opened this issue Oct 30, 2012 · 8 comments · Fixed by #35

Comments

@ChristianGruen
Copy link
Member

Hi Adam, I noticed that the schema of the <http:response/> element is different to the one proposed in the EXPath HTTP specification:

http://www.expath.org/spec/http-client#d2e491

For example, the message attribute name is called reason in the XMLPrague proposal for RESTXQ. Next, there is no <http:body/> element. Instead, all results are returned as additional items.. which is of course reasonable if we plan to also return non-textual data.

@adamretter
Copy link
Member

Hi Christian, terribly sorry. For some reason I completely missed this. Is it still something you need an answer on?

@ChristianGruen
Copy link
Member Author

Hi Adam, I stumbled upon this issue, because @dizzzz changed a little example in our documentation (http://docs.basex.org/index.php?title=RESTXQ&action=historysubmit&diff=13833&oldid=13809 …hi Dannes!).

In the specifications…

…the response attribute is called message, so maybe we should change this back from reason to message?

The current version of the BaseX RESTXQ implementation provides support for both attributes.

@ChristianGruen
Copy link
Member Author

Hi Dannes, hi Adam, do you have any opinion on this? Thanks in advance!

@dizzzz
Copy link
Contributor

dizzzz commented May 31, 2018

I have no strong opinion here, as long it works cross-vendor :)
IMO we need to follow the spec, and if eXist deviates here, we have a bug and need to fix it.

in eXist-db: For compatibility i’d Like to support both attributes..... at least for some time. But the code will be a bit ugly :-)

@dizzzz
Copy link
Contributor

dizzzz commented May 31, 2018

suggested fix in PR #35

@ChristianGruen
Copy link
Member Author

Thanks for your feedback, Dannes!

@dizzzz
Copy link
Contributor

dizzzz commented Jun 8, 2018

We have to undo the wiki change :)

@ChristianGruen
Copy link
Member Author

Just done ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants