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