<xs:schema id="schema-images" xmlns:xs="http://www.w3.org/2001/XMLSchema%22elementFormDefault ="qualified"> <xs:include schemaLocation="HowToContent_Common.xsd"/> ... </xs:element> </xs:schema>
Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd.
Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path.
<!ENTITY % common
PUBLIC "-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod"> %common;
How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this:
*let* *$xsd* := *db:open*('AppResources')/*[*@id*=*$xsd-id*]
*try* { *validate:xsd*(*$xml-file*, *$xsd*) } *catch* *** { <li *style*=*"color:red;"*><p>File '{* $xml-file*/*base-uri*()}' doesn't validate against the '{*$xsd*/* base-uri*()}' schema.</p><p>{'Error [' || *$err:code* || ']: ' || * $err:description*}</p></li> }
My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working.
I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help.
Regards,
France
Dear France,
thanks for your e-mail. As XSD validation is an external process, it may be that some relative path references are not correctly resolved. Do you have small example files that allow us to reproduce the behavior?
Best, Christian ___________________________
2013/7/15 France Baril france.baril@architextus.com:
<xs:schema id="schema-images" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:include schemaLocation="HowToContent_Common.xsd"/> ... </xs:element> </xs:schema>
Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd.
Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path.
<!ENTITY % common PUBLIC "-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod">
%common;
How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this:
let $xsd := db:open('AppResources')/*[@id=$xsd-id]
try { validate:xsd($xml-file, $xsd) } catch * { <li style="color:red;"><p>File '{$xml-file/base-uri()}' doesn't validate against the '{$xsd/base-uri()}' schema.</p><p>{'Error [' || $err:code || ']: ' || $err:description}</p></li> }
My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working.
I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help.
Regards,
France
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com (514) 572-0341
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
Dear France, try to change the call to validate:xsd by passing in the URI to the file instead of the xsd document. I remember that there was an issue we discussed several months ago about the XSD validation and XSLT transformation and the URI resolution that Christian fixed for the scenario where URIs are directly passed to the functions as strings [1]. Marco.
[1] Message ID: CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com with subject "URI resolution" and related thread ....
On 07/15/2013 09:21 PM, France Baril wrote:
xs:schemaid="schema-images"xmlns:xs="http://www.w3.org/2001/XMLSchema"elementFormDefault="qualified" xs:includeschemaLocation="HowToContent_Common.xsd"/ ... </xs:element> </xs:schema>
Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd.
Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path.
<!ENTITY% common PUBLIC"-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod">
%common;
How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this:
*let**$xsd*:= /db:open/('AppResources')/*[*/@id/*=*$xsd-id*]
*try* { /validate:xsd/(*$xml-file*, *$xsd*) } *catch* *** {
<li *style*=*"color:red;"*><p>File '{*$xml-file*//base-uri/()}' doesn't validate against the '{*$xsd*//base-uri/()}' schema.</p><p>{'Error [' || *$err:code* || ']: ' || *$err:description*}</p></li> }
My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working.
I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help.
Regards,
France
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com mailto:france.baril@architextus.com (514) 572-0341
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
When I use the base-uri() I get the same issue. Normally in function from the db module I have to specify *substring-after*(*$xsd*/*base-uri*(), 'AppResources/') where 'AppResources' would be the database name. Ex db:open('AppResources', *substring-after*(*$xsd*/*base-uri*(), 'AppResources/') ). I tried with both the full base-uri() and the base-uri() after the DB name, although I'm unsure how the DB name would get resolved in the case of the validate module. None worked.
I get: [err:FODC0002]: Resource 'dtds/images.xsd' does not exist.
Or: [err:FODC0002]: Resource 'AppResources/dtds/images.xsd' does not exist.
At least with the previous one I was getting passed these with:
[bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component."
I am attaching a simple case with a minimal XSD and a minimal file. You can access http://localhost:8984/restxq/testxsd/test after installing the DB and restxq. When I run it I get:
File 'DebugXsdRef/images.xml' doesn't validate against the 'DebugXsdRef/images.xsd' schema.
Error [bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component."
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps, but when accessing the DB though XML Oxygen/WebDAV connection, I see that the file has not really been renamed Anyhow, it might have a link with the reference not being resolved properly (?).
[image: Inline image 2][image: Inline image 1]
On Tue, Jul 16, 2013 at 4:59 AM, Marco Lettere marco.lettere@dedalus.euwrote:
Dear France, try to change the call to validate:xsd by passing in the URI to the file instead of the xsd document. I remember that there was an issue we discussed several months ago about the XSD validation and XSLT transformation and the URI resolution that Christian fixed for the scenario where URIs are directly passed to the functions as strings [1]. Marco.
[1] Message ID: CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.comCAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.comwith subject "URI resolution" and related thread ....
On 07/15/2013 09:21 PM, France Baril wrote:
<xs:schema id="schema-images" xmlns:xs="http://www.w3.org/2001/XMLSchema%22elementFormDefault ="qualified"> <xs:include schemaLocation="HowToContent_Common.xsd"/> ... </xs:element> </xs:schema>
Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd.
Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path.
<!ENTITY % common PUBLIC "-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod">
%common;
How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this:
*let* *$xsd* := *db:open*('AppResources')/*[*@id*=*$xsd-id*]
*try* { *validate:xsd*(*$xml-file*, *$xsd*) } *catch* *** { <li *style*=*"color:red;"*><p>File '{* $xml-file*/*base-uri*()}' doesn't validate against the '{*$xsd*/* base-uri*()}' schema.</p><p>{'Error [' || *$err:code* || ']: ' || * $err:description*}</p></li> }
My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working.
I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help.
Regards,
France
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com (514) 572-0341
BaseX-Talk mailing listBaseX-Talk@mailman.uni-konstanz.dehttps://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
For us everything started to work correctly (also import of other schemas) as soon as we moved the XSD from the database to the file system and used the validation functions by passing in the path to the root XSD. Is it necessary for you to keep the XSD inside the database? M.
On 07/16/2013 06:57 PM, France Baril wrote:
When I use the base-uri() I get the same issue. Normally in function from the db module I have to specify /substring-after/(*$xsd*//base-uri/(), 'AppResources/')where 'AppResources' would be the database name. Ex db:open('AppResources', /substring-after/(*$xsd*//base-uri/(), 'AppResources/') ). I tried with both the full base-uri() and the base-uri() after the DB name, although I'm unsure how the DB name would get resolved in the case of the validate module. None worked.
I get: [err:FODC0002]: Resource 'dtds/images.xsd' does not exist.
Or:[err:FODC0002]: Resource 'AppResources/dtds/images.xsd' does not exist.
At least with the previous one I was getting passed these with:
[bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component."
I am attaching a simple case with a minimal XSD and a minimal file. You can access http://localhost:8984/restxq/testxsd/test after installing the DB and restxq. When I run it I get:
File 'DebugXsdRef/images.xml' doesn't validate against the 'DebugXsdRef/images.xsd' schema.
Error [bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component."
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps, but when accessing the DB though XML Oxygen/WebDAV connection, I see that the file has not really been renamed Anyhow, it might have a link with the reference not being resolved properly (?).
Inline image 2Inline image 1
On Tue, Jul 16, 2013 at 4:59 AM, Marco Lettere <marco.lettere@dedalus.eu mailto:marco.lettere@dedalus.eu> wrote:
Dear France, try to change the call to validate:xsd by passing in the URI to the file instead of the xsd document. I remember that there was an issue we discussed several months ago about the XSD validation and XSLT transformation and the URI resolution that Christian fixed for the scenario where URIs are directly passed to the functions as strings [1]. Marco. [1] Message ID: <CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com> <mailto:CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com> with subject "URI resolution" and related thread .... On 07/15/2013 09:21 PM, France Baril wrote:<xs:schemaid="schema-images"xmlns:xs="http://www.w3.org/2001/XMLSchema"elementFormDefault="qualified"> <xs:includeschemaLocation="HowToContent_Common.xsd"/> ... </xs:element> </xs:schema> Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd. Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path. <!ENTITY% common PUBLIC"-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod"> %common; How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this: *let**$xsd*:= /db:open/('AppResources')/*[*/@id/*=*$xsd-id*] *try* { /validate:xsd/(*$xml-file*, *$xsd*) } *catch* *** { <li *style*=*"color:red;"*><p>File '{*$xml-file*//base-uri/()}' doesn't validate against the '{*$xsd*//base-uri/()}' schema.</p><p>{'Error [' || *$err:code* || ']: ' || *$err:description*}</p></li> } My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working. I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help. Regards, France -- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com <mailto:france.baril@architextus.com> (514) 572-0341 <tel:%28514%29%20572-0341> _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de <mailto:BaseX-Talk@mailman.uni-konstanz.de> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de <mailto:BaseX-Talk@mailman.uni-konstanz.de> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com mailto:france.baril@architextus.com (514) 572-0341
Hi,
Yes, for us keeping the XSD in the DB is important.
The point of moving from DTD to XSD is that the XSD is XML, so I can use the power of xquery to generate the user documentation for authors: extract parent, children and attributes, and dynamically insert descriptions for each.
Also, having all application files in a DB (our Application Resource DB) limits issues (configuration differences) when upgrading our different systems: dev on Mac OS, user feedback on Linux (WAR), authoring system on a Windows server. The further away we stay from the file system, the happier/more productive we are.
Maintaining the 2 sets (DTD/XSD) is getting impractical as we multiply the number of models.
Regards,
France
On Wed, Jul 17, 2013 at 3:10 AM, Marco Lettere marco.lettere@dedalus.euwrote:
For us everything started to work correctly (also import of other schemas) as soon as we moved the XSD from the database to the file system and used the validation functions by passing in the path to the root XSD. Is it necessary for you to keep the XSD inside the database? M.
On 07/16/2013 06:57 PM, France Baril wrote:
When I use the base-uri() I get the same issue. Normally in function from the db module I have to specify *substring-after*(*$xsd*/*base-uri* (), 'AppResources/') where 'AppResources' would be the database name. Ex db:open('AppResources', *substring-after*(*$xsd*/*base-uri*(), 'AppResources/') ). I tried with both the full base-uri() and the base-uri() after the DB name, although I'm unsure how the DB name would get resolved in the case of the validate module. None worked.
I get: [err:FODC0002]: Resource 'dtds/images.xsd' does not exist.
Or: [err:FODC0002]: Resource 'AppResources/dtds/images.xsd' does not exist.
At least with the previous one I was getting passed these with:
[bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component."
I am attaching a simple case with a minimal XSD and a minimal file. You can access http://localhost:8984/restxq/testxsd/test after installing the DB and restxq. When I run it I get:
File 'DebugXsdRef/images.xml' doesn't validate against the 'DebugXsdRef/images.xsd' schema.
Error [bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component."
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps, but when accessing the DB though XML Oxygen/WebDAV connection, I see that the file has not really been renamed Anyhow, it might have a link with the reference not being resolved properly (?).
[image: Inline image 2][image: Inline image 1]
On Tue, Jul 16, 2013 at 4:59 AM, Marco Lettere marco.lettere@dedalus.euwrote:
Dear France, try to change the call to validate:xsd by passing in the URI to the file instead of the xsd document. I remember that there was an issue we discussed several months ago about the XSD validation and XSLT transformation and the URI resolution that Christian fixed for the scenario where URIs are directly passed to the functions as strings [1]. Marco.
[1] Message ID: CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.comCAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.comwith subject "URI resolution" and related thread ....
On 07/15/2013 09:21 PM, France Baril wrote:
<xs:schema id="schema-images" xmlns:xs=" http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:include schemaLocation="HowToContent_Common.xsd"/> ... </xs:element> </xs:schema>
Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd.
Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path.
<!ENTITY % common PUBLIC "-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod">
%common;
How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this:
*let* *$xsd* := *db:open*('AppResources')/*[*@id*=*$xsd-id*]
*try* { *validate:xsd*(*$xml-file*, *$xsd*) } *catch* *** { <li *style*=*"color:red;"*><p>File '{* $xml-file*/*base-uri*()}' doesn't validate against the '{*$xsd*/* base-uri*()}' schema.</p><p>{'Error [' || *$err:code* || ']: ' || * $err:description*}</p></li> }
My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working.
I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help.
Regards,
France
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com (514) 572-0341 <%28514%29%20572-0341>
BaseX-Talk mailing listBaseX-Talk@mailman.uni-konstanz.dehttps://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com (514) 572-0341
I see, well one could try by keeping the XSDs in the DB and access them through the REST interface. So instead of a file path in the validate you could pass HTTP URIs .... maybe?
M.
On 07/17/2013 12:18 PM, France Baril wrote:
Hi,
Yes, for us keeping the XSD in the DB is important.
The point of moving from DTD to XSD is that the XSD is XML, so I can use the power of xquery to generate the user documentation for authors: extract parent, children and attributes, and dynamically insert descriptions for each.
Also, having all application files in a DB (our Application Resource DB) limits issues (configuration differences) when upgrading our different systems: dev on Mac OS, user feedback on Linux (WAR), authoring system on a Windows server. The further away we stay from the file system, the happier/more productive we are.
Maintaining the 2 sets (DTD/XSD) is getting impractical as we multiply the number of models.
Regards,
France
On Wed, Jul 17, 2013 at 3:10 AM, Marco Lettere <marco.lettere@dedalus.eu mailto:marco.lettere@dedalus.eu> wrote:
For us everything started to work correctly (also import of other schemas) as soon as we moved the XSD from the database to the file system and used the validation functions by passing in the path to the root XSD. Is it necessary for you to keep the XSD inside the database? M. On 07/16/2013 06:57 PM, France Baril wrote:When I use the base-uri() I get the same issue. Normally in function from the db module I have to specify /substring-after/(*$xsd*//base-uri/(), 'AppResources/')where 'AppResources' would be the database name. Ex db:open('AppResources', /substring-after/(*$xsd*//base-uri/(), 'AppResources/') ). I tried with both the full base-uri() and the base-uri() after the DB name, although I'm unsure how the DB name would get resolved in the case of the validate module. None worked. I get: [err:FODC0002]: Resource 'dtds/images.xsd' does not exist. Or:[err:FODC0002]: Resource 'AppResources/dtds/images.xsd' does not exist. At least with the previous one I was getting passed these with: [bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component." I am attaching a simple case with a minimal XSD and a minimal file. You can access http://localhost:8984/restxq/testxsd/test after installing the DB and restxq. When I run it I get: File 'DebugXsdRef/images.xml' doesn't validate against the 'DebugXsdRef/images.xsd' schema. Error [bxerr:BXVA0001]: Validation failed. "Fatal: src-resolve: Cannot resolve the name 'filter-atts' to a(n) 'attribute group' component." NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps, but when accessing the DB though XML Oxygen/WebDAV connection, I see that the file has not really been renamed Anyhow, it might have a link with the reference not being resolved properly (?). Inline image 2Inline image 1 On Tue, Jul 16, 2013 at 4:59 AM, Marco Lettere <marco.lettere@dedalus.eu <mailto:marco.lettere@dedalus.eu>> wrote: Dear France, try to change the call to validate:xsd by passing in the URI to the file instead of the xsd document. I remember that there was an issue we discussed several months ago about the XSD validation and XSLT transformation and the URI resolution that Christian fixed for the scenario where URIs are directly passed to the functions as strings [1]. Marco. [1] Message ID: <CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com> <mailto:CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com> with subject "URI resolution" and related thread .... On 07/15/2013 09:21 PM, France Baril wrote:<xs:schemaid="schema-images"xmlns:xs="http://www.w3.org/2001/XMLSchema"elementFormDefault="qualified"> <xs:includeschemaLocation="HowToContent_Common.xsd"/> ... </xs:element> </xs:schema> Does not pickup the definitions in the common .xsd files when running validate:xsd. It returns errors for items defined in the 'included' .xsd. Referencing a 'sub-DTD' does work with the DTD (validate:dtd) when the common element is included using a similar path. <!ENTITY% common PUBLIC"-//MOTOROLA//DTD HOW2 COMMON//EN" "HowToContent_Common.mod"> %common; How do I get validate:xsd to grab the sub-components? I'm currently using validate:xsd like this: *let**$xsd*:= /db:open/('AppResources')/*[*/@id/*=*$xsd-id*] *try* { /validate:xsd/(*$xml-file*, *$xsd*) } *catch* *** { <li *style*=*"color:red;"*><p>File '{*$xml-file*//base-uri/()}' doesn't validate against the '{*$xsd*//base-uri/()}' schema.</p><p>{'Error [' || *$err:code* || ']: ' || *$err:description*}</p></li> } My files validate correctly when I run validation in XML Oxygen, so I know the XSD itself is working. I tried using lower caps in the xs:include reference as I noticed that the .xsd files get renamed to lower caps on import (but not DTDs [because they were considered raw and unindexed?]). Anyhow, it didn't help. Regards, France -- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com <mailto:france.baril@architextus.com> (514) 572-0341 <tel:%28514%29%20572-0341> _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de <mailto:BaseX-Talk@mailman.uni-konstanz.de> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk_______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de <mailto:BaseX-Talk@mailman.uni-konstanz.de> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk -- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com <mailto:france.baril@architextus.com> (514) 572-0341 <tel:%28514%29%20572-0341>-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com mailto:france.baril@architextus.com (514) 572-0341
Hi France,
thanks, the example was helpful. As we use standard Java code to validate XML documents, the validation process can only access retrieve documents from default URLs. If the URL is relative, it will be resolved from the current working directory Java has been started from.
However, one solution is to temporarily write the relevant database files to disk before validating the document, and removing them again after the process. The attached TestXsd.xqm file indicates how this can be done.
If you want to avoid spamming your current working directory, you can also write all files to a temporary directory. In this case, you’ll also have to update the schema locations in the specified schema file. TestXsd-temp.xqm presents a solution for this alternative.
I agree that it would feel more elegant if validation would exclusively work on database resources, but at least I’m quite sure that the proposed shouldn’t introduce any remarkable slowdown.
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps [...]
True; we have an open issue in our bug tracker that addresses this inconsistency [1]. We hope to get it fixed until the final 7.7 release (which is planned to be aligned with this year’s Balisage Conference in Montréal… ;).
Christian
Our experience shows that delivery on a web server with a WAR file doesn't easily allow for write-access to the file system.
I created a function that resolves the includes recursively and returns the full .xsd, then I send that new node to validate:xsd.
Seems to resolve the issue for now.
Regards,
France
On Wed, Jul 17, 2013 at 7:31 AM, Christian Grün christian.gruen@gmail.comwrote:
Hi France,
thanks, the example was helpful. As we use standard Java code to validate XML documents, the validation process can only access retrieve documents from default URLs. If the URL is relative, it will be resolved from the current working directory Java has been started from.
However, one solution is to temporarily write the relevant database files to disk before validating the document, and removing them again after the process. The attached TestXsd.xqm file indicates how this can be done.
If you want to avoid spamming your current working directory, you can also write all files to a temporary directory. In this case, you’ll also have to update the schema locations in the specified schema file. TestXsd-temp.xqm presents a solution for this alternative.
I agree that it would feel more elegant if validation would exclusively work on database resources, but at least I’m quite sure that the proposed shouldn’t introduce any remarkable slowdown.
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps [...]
True; we have an open issue in our bug tracker that addresses this inconsistency [1]. We hope to get it fixed until the final 7.7 release (which is planned to be aligned with this year’s Balisage Conference in Montréal… ;).
Christian
Follow up: it turns out the includes and imports work when the .xsd is accessed using the rest path: http://domain/rest/db/collection(s)/file.xsd.
Ex. validate:xsd($xml-file, 'http://domain/rest/db/collection(s)/file.xsd')
On Thu, Jul 18, 2013 at 3:52 PM, France Baril france.baril@architextus.comwrote:
Our experience shows that delivery on a web server with a WAR file doesn't easily allow for write-access to the file system.
I created a function that resolves the includes recursively and returns the full .xsd, then I send that new node to validate:xsd.
Seems to resolve the issue for now.
Regards,
France
On Wed, Jul 17, 2013 at 7:31 AM, Christian Grün <christian.gruen@gmail.com
wrote:
Hi France,
thanks, the example was helpful. As we use standard Java code to validate XML documents, the validation process can only access retrieve documents from default URLs. If the URL is relative, it will be resolved from the current working directory Java has been started from.
However, one solution is to temporarily write the relevant database files to disk before validating the document, and removing them again after the process. The attached TestXsd.xqm file indicates how this can be done.
If you want to avoid spamming your current working directory, you can also write all files to a temporary directory. In this case, you’ll also have to update the schema locations in the specified schema file. TestXsd-temp.xqm presents a solution for this alternative.
I agree that it would feel more elegant if validation would exclusively work on database resources, but at least I’m quite sure that the proposed shouldn’t introduce any remarkable slowdown.
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps [...]
True; we have an open issue in our bug tracker that addresses this inconsistency [1]. We hope to get it fixed until the final 7.7 release (which is planned to be aligned with this year’s Balisage Conference in Montréal… ;).
Christian
-- France Baril Architecte documentaire / Documentation architect france.baril@architextus.com (514) 572-0341
NOTE: When I look at the file in BaseX GUI, I see the .xsd file renamed as lower caps, but when accessing the DB though XML Oxygen/WebDAV connection, I see that the file has not really been renamed Anyhow, it might have a link with the reference not being resolved properly (?).
I have uploaded a new snapshot which addresses this issue [1]. I hope it’s solving the problem?
Christian
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
France Baril -
Marco Lettere