Main Page » Mailing List » July 2013

get validate:xsd to work like validate:dtd

Monday, 15 July 2013 · 11 messages · last reply 1 Aug 2013
FB
France Baril15 Jul 2013 23:21 #
<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&apos;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 at architextus.com (514) 572-0341
CG
Christian Grün16 Jul 2013 09:41 #
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 at architextus.com>:
Quoted text · France Baril · 58 lines
> <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&apos;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 at architextus.com > (514) 572-0341 > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
ML
Marco Letterein reply to France Baril, 15 Jul 2013, 23:2116 Jul 2013 10:59 #
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 at mail.gmail.com> with subject "URI resolution" and related thread ....
Quoted text · France Baril · 60 lines
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&apos;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 at architextus.com <mailto:france.baril at architextus.com> > (514) 572-0341 > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
FB
France Baril16 Jul 2013 20:58 #
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 at dedalus.eu>wrote:
Quoted text · Marco Lettere · 76 lines
> 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 at mail.gmail.com><CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com>with 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&apos;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 at architextus.com > (514) 572-0341 > > > _______________________________________________ > BaseX-Talk mailing listBaseX-Talk at mailman.uni-konstanz.dehttps://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > >
-- France Baril Architecte documentaire / Documentation architect france.baril at architextus.com (514) 572-0341
ML
Marco Lettere17 Jul 2013 09:10 #
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.
Quoted text · France Baril · 140 lines
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 at dedalus.eu <mailto:marco.lettere at 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 at mail.gmail.com> > <mailto:CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw at 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&apos;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 at architextus.com <mailto:france.baril at architextus.com> >> (514) 572-0341 <tel:%28514%29%20572-0341> >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de <mailto:BaseX-Talk at mailman.uni-konstanz.de> >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > <mailto:BaseX-Talk at mailman.uni-konstanz.de> > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > > > > -- > France Baril > Architecte documentaire / Documentation architect > france.baril at architextus.com <mailto:france.baril at architextus.com> > (514) 572-0341
ML
Marco Letterein reply to France Baril, 17 Jul 2013, 14:1917 Jul 2013 12:32 #
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.
Quoted text · France Baril · 190 lines
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 at dedalus.eu <mailto:marco.lettere at 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 at dedalus.eu <mailto:marco.lettere at 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 at mail.gmail.com> >> <mailto:CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw at 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&apos;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 at architextus.com >>> <mailto:france.baril at architextus.com> >>> (514) 572-0341 <tel:%28514%29%20572-0341> >>> >>> >>> _______________________________________________ >>> BaseX-Talk mailing list >>> BaseX-Talk at mailman.uni-konstanz.de <mailto:BaseX-Talk at mailman.uni-konstanz.de> >>> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> <mailto:BaseX-Talk at mailman.uni-konstanz.de> >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >> >> >> >> -- >> France Baril >> Architecte documentaire / Documentation architect >> france.baril at architextus.com <mailto:france.baril at architextus.com> >> (514) 572-0341 <tel:%28514%29%20572-0341> > > > > > -- > France Baril > Architecte documentaire / Documentation architect > france.baril at architextus.com <mailto:france.baril at architextus.com> > (514) 572-0341
CG
Christian Grünin reply to France Baril, 17 Jul 2013, 14:1917 Jul 2013 13:31 #
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.
Quoted text · France Baril · 2 lines
> 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 [1] https://github.com/BaseXdb/basex/issues/564
FB
France Barilin reply to Marco Lettere, 17 Jul 2013, 09:1017 Jul 2013 14:19 #
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 at dedalus.eu>wrote:
Quoted text · Marco Lettere · 138 lines
> 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 at 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 at mail.gmail.com><CAP94bnOEv3oskaQOiRMzdEmnhxn6zuDXHYxCoOSrkvdAdBzQzw@mail.gmail.com>with 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&apos;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 at architextus.com >> (514) 572-0341 <%28514%29%20572-0341> >> >> >> _______________________________________________ >> BaseX-Talk mailing listBaseX-Talk at mailman.uni-konstanz.dehttps://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >> >> >> _______________________________________________ >> BaseX-Talk mailing list >> BaseX-Talk at mailman.uni-konstanz.de >> https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >> >> > > > -- > France Baril > Architecte documentaire / Documentation architect > france.baril at architextus.com > (514) 572-0341 > > >
-- France Baril Architecte documentaire / Documentation architect france.baril at architextus.com (514) 572-0341
CG
Christian Grünin reply to France Baril, 16 Jul 2013, 20:5817 Jul 2013 15:24 #
Quoted text · France Baril · 4 lines
> 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 [1] http://files.basex.org/releases/latest/
FB
France Barilin reply to Christian Grün, 17 Jul 2013, 13:3118 Jul 2013 23:53 #
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 at gmail.com>wrote:
Quoted text · Christian Grün · 34 lines
> 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 > > [1] https://github.com/BaseXdb/basex/issues/564 >
-- France Baril Architecte documentaire / Documentation architect france.baril at architextus.com (514) 572-0341
FB
France Baril1 Aug 2013 20:48 #
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 at architextus.com>wrote:
Quoted text · France Baril · 62 lines
> 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 at 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 >> >> [1] https://github.com/BaseXdb/basex/issues/564 >> > > > > -- > France Baril > Architecte documentaire / Documentation architect > france.baril at architextus.com > (514) 572-0341 >
-- France Baril Architecte documentaire / Documentation architect france.baril at architextus.com (514) 572-0341

Written for BaseX 7.6. BaseX may have changed since: please check the current documentation.

« Basex collection sizePossibly related parsing issue Re: get validate:xsd to work like validate:dtd »
⚡Generated with XQuery