Hi Elina, (cc: basex-talk)
Happy to help. That email correspondence is a bit old, and the code referenced is ancient. I suspect your problems creating the headers in XQuery restxq are due to default namespace prefix changes, rest vs restxq, way back when.
You are correct that enabling the supplied CORS filter in web.xml works for GET and POST but not PUT. The reason is that PUT is not in the default AllowedMethods [1]
As an exercise I have created a little sample that uses only RESTXQ facilities. [2] It assumes the web.xml CORS filter is not enabled.
As supplied it has: A cors.html file, to be opened directly in the browser, i.e. using the file protocol. A cors.xqm intended to be put in the webapp folder of a local basexhttp running on 8984
Only the PUT request is allowed as I have commented out the Xquery generation of the CORS headers for GET and POST. Note PUT is a non-simple CORS request and will result in the browser sending an additional request using the OPTIONS method [3] This can be seen in the screenshot and is handled in the cors.xqm code.
Hope this helps /Andy
[1] https://www.eclipse.org/jetty/documentation/current/cross-origin-filter.html [2] https://gist.github.com/apb2006/ea6a901a570b04f94e0e0e21098a5402 [3] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests
[image: image.png]
On Fri, 7 Aug 2020 at 13:53, Elina Koskentalo ekoskent@gmail.com wrote:
Hello Andy,
I hope you don't mind me contacting you, I found this email corresponding between you and another person about BaseX and adding the Access-Control-Allow-Origin header to the response. https://mailman.uni-konstanz.de/pipermail/basex-talk/2017-February/011782.ht...
I have a very similar issue than what you are talking about there. I don't manage to define a rule in the restxq file that would simply add Access-Control-Allow-Origin header to or requests. I already manipulated the filters in the web.xml file which now works for GET but for PUT I still get the CORS issue back.
Would you have any tips for me? Thank you very much in advance!
Best regards, Elina Koskentalo ekoskent@gmail.com
Using 9.4.2 and 943-20200826.181852 I get the same result:
let $test as element(root) := <root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "content"})
does not work, in the sense that no CDATA block is created.
let $test as element(root) := <root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
does work, in the sense that the text contents of div gets wrapped in CDATA.
If I try let $test as element(root) := <root> <content> <div>words <b>bold</b> words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
I get
<root> <content> <div><![CDATA[words ]]><b>bold</b><![CDATA[ words]]></div> </content> </root>
which makes me think that only text node children of the element get wrapped in a CDATA block.
I would expect (from the way XSLT processors usually behave) that the content of an element with element children would be serialized into a CDATA block. Am I confused? Is this a bug? is there a more appropriate way to declare the contents of the content element a CDATA block?
Thanks! Graydon
Hi Graydon,
I can’t say much about serialization in XSLT, but the serialization of CDATA sections in XQuery is indeed focused on text nodes [1]:
“The cdata-section-elements parameter contains a list of expanded QNames. If the expanded QName of the parent of a text node is a member of the list, then the text node MUST be output as a CDATA section, […].”
If you want to serialize the descendants of specific elements as text, you could try this:
declare option output:method 'xml'; declare option output:cdata-section-elements 'div';
let $test := <root> <content> <div>words <b>bold</b> words</div> </content> </root> return $test update { .//div ! (replace value of node . with serialize(node())) }
Hope this helps, Christian
[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#XML_CDATA-SECTION-ELEMEN...
On Wed, Aug 26, 2020 at 11:00 PM Graydon Saunders graydonish@gmail.com wrote:
Using 9.4.2 and 943-20200826.181852 I get the same result:
let $test as element(root) :=
<root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "content"})
does not work, in the sense that no CDATA block is created.
let $test as element(root) :=
<root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
does work, in the sense that the text contents of div gets wrapped in CDATA.
If I try let $test as element(root) :=
<root> <content> <div>words <b>bold</b> words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
I get
<root> <content> <div><![CDATA[words ]]><b>bold</b><![CDATA[ words]]></div> </content> </root>
which makes me think that only text node children of the element get wrapped in a CDATA block.
I would expect (from the way XSLT processors usually behave) that the content of an element with element children would be serialized into a CDATA block. Am I confused? Is this a bug? is there a more appropriate way to declare the contents of the content element a CDATA block?
Thanks! Graydon
Hi Christian --
Or I could just be a simple creature and use let $test as element(root) := <root> <content>{serialize( <div>words <b>bold</b> words</div> )} </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "content"})
Which gives
<root> <content><![CDATA[<div>words <b>bold</b> words</div>]]></content> </root>
(Your solution is considerably more elegant but would be much trickier to use the actual case.)
Thank you!
On Wed, Aug 26, 2020 at 5:12 PM Christian Grün christian.gruen@gmail.com wrote:
Hi Graydon,
I can’t say much about serialization in XSLT, but the serialization of CDATA sections in XQuery is indeed focused on text nodes [1]:
“The cdata-section-elements parameter contains a list of expanded QNames. If the expanded QName of the parent of a text node is a member of the list, then the text node MUST be output as a CDATA section, […].”
If you want to serialize the descendants of specific elements as text, you could try this:
declare option output:method 'xml'; declare option output:cdata-section-elements 'div';
let $test := <root>
<content> <div>words <b>bold</b> words</div> </content> </root> return $test update { .//div ! (replace value of node . with serialize(node())) }
Hope this helps, Christian
[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#XML_CDATA-SECTION-ELEMEN...
On Wed, Aug 26, 2020 at 11:00 PM Graydon Saunders graydonish@gmail.com wrote:
Using 9.4.2 and 943-20200826.181852 I get the same result:
let $test as element(root) :=
<root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "content"})
does not work, in the sense that no CDATA block is created.
let $test as element(root) :=
<root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
does work, in the sense that the text contents of div gets wrapped in
CDATA.
If I try let $test as element(root) :=
<root> <content> <div>words <b>bold</b> words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
I get
<root> <content> <div><![CDATA[words ]]><b>bold</b><![CDATA[ words]]></div> </content> </root>
which makes me think that only text node children of the element get
wrapped in a CDATA block.
I would expect (from the way XSLT processors usually behave) that the
content of an element with element children would be serialized into a CDATA block. Am I confused? Is this a bug? is there a more appropriate way to declare the contents of the content element a CDATA block?
Thanks! Graydon
…perfectly fine of course! As the update keyword is BaseX-specific, your code (in contrast to mine) will also run with other processors with support for the File Module (such as Saxon).
Graydon Saunders graydonish@gmail.com schrieb am Mi., 26. Aug. 2020, 23:49:
Hi Christian --
Or I could just be a simple creature and use let $test as element(root) :=
<root> <content>{serialize( <div>words <b>bold</b> words</div> )} </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "content"})
Which gives
<root> <content><![CDATA[<div>words <b>bold</b> words</div>]]></content> </root>
(Your solution is considerably more elegant but would be much trickier to use the actual case.)
Thank you!
On Wed, Aug 26, 2020 at 5:12 PM Christian Grün christian.gruen@gmail.com wrote:
Hi Graydon,
I can’t say much about serialization in XSLT, but the serialization of CDATA sections in XQuery is indeed focused on text nodes [1]:
“The cdata-section-elements parameter contains a list of expanded QNames. If the expanded QName of the parent of a text node is a member of the list, then the text node MUST be output as a CDATA section, […].”
If you want to serialize the descendants of specific elements as text, you could try this:
declare option output:method 'xml'; declare option output:cdata-section-elements 'div';
let $test := <root>
<content> <div>words <b>bold</b> words</div> </content> </root> return $test update { .//div ! (replace value of node . with serialize(node())) }
Hope this helps, Christian
[1] https://www.w3.org/TR/xslt-xquery-serialization-31/#XML_CDATA-SECTION-ELEMEN...
On Wed, Aug 26, 2020 at 11:00 PM Graydon Saunders graydonish@gmail.com wrote:
Using 9.4.2 and 943-20200826.181852 I get the same result:
let $test as element(root) :=
<root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "content"})
does not work, in the sense that no CDATA block is created.
let $test as element(root) :=
<root> <content> <div>words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
does work, in the sense that the text contents of div gets wrapped in
CDATA.
If I try let $test as element(root) :=
<root> <content> <div>words <b>bold</b> words</div> </content> </root>
return file:write('/home/graydon/test2.xml', $test, map { "method": "xml", "cdata-section-elements": "div"})
I get
<root> <content> <div><![CDATA[words ]]><b>bold</b><![CDATA[ words]]></div> </content> </root>
which makes me think that only text node children of the element get
wrapped in a CDATA block.
I would expect (from the way XSLT processors usually behave) that the
content of an element with element children would be serialized into a CDATA block. Am I confused? Is this a bug? is there a more appropriate way to declare the contents of the content element a CDATA block?
Thanks! Graydon
basex-talk@mailman.uni-konstanz.de
-
Andy Bunce -
Christian Grün -
Graydon Saunders