Re: [basex-talk] xslt:transform function not working with XML Catalog
Hi Vincent,
I feel your pain. Maybe this comment helps:
https://github.com/BaseXdb/basex/issues/1793#issuecomment-579134499
(omit the quotes in the pragma).
I documented it here, too:
https://docs.basex.org/wiki/Catalog_Resolver#Additional_Notes
“The catalog location in the pragma can be given relative to the current
working directory (the directory that is returned by file:current-dir())
or as an absolute operating system path. The catalog location in the
pragma is not an XQuery expression; no concatenation or other operations
may occur in the pragma, and the location string must not be surrounded
by quotes.”
Gerrit
On 09.07.2020 06:32, Lizzi, Vincent wrote:
Hi Liam,
Thanks for the reply and suggestions. Based on your suggestion I tried
pragmas and strace, and had another go at CatalogManager.properties, but
they’ve not had any effect. (I’m using Windows 10 but was able to run
strace in Ubuntu via WSL). This query:
try {
(# db:catfile 'schemas/catalog.xml' #)
(# db:intparse false #)
(# db:dtd true #)
(# db:chop false #)
{ xslt:transform('file.xml’, 'stylesheet.xsl')//inlinegraphic }
} catch * { $err:description }
Produces the same error again due to the DTD not being available at the
system literal URI.
I did try setting verbosity 99 in a CatalogManager.properties file on
the classpath, but this did not produce any additional messages. I also
tried setting the same properties directly when launching BaseX this did
not work either. Specifically, I set the following system properties
when launching BaseX, and then used proc:property() in a query to
confirm that these system properties were in fact set.
'xml.catalog.verbosity': '99'
'xml.catalog.ignoreMissing': 'no'
'xml.catalog.catalog-class-name': 'org.apache.xml.resolver.Resolver'
'xml.catalog.files': 'schemas/catalog.xml'
xml-resolver-1.2.jar and Saxon are definitely on the classpath.
Thanks,
VIncent
_
*Vincent M. Lizzi*
Head of Information Standards | Taylor & Francis Group
vincent.li...@taylorandfrancis.com
Information Classification: General
*From:* Liam R. E. Quin
*Sent:* Wednesday, July 8, 2020 10:28 PM
*To:* Lizzi, Vincent ; BaseX
*Subject:* Re: [basex-talk] xslt:transform function not working with XML
Catalog
On Wed, 2020-07-08 at 22:46 +, Lizzi, Vincent wrote:
> I've encountered a problem using xslt:transform in to transform some
> old XML that contains a DTD DOCTYPE system literal pointing to a non-
> working URI and also uses ENTITYREF attributes to refer to image
> files. I have the XML Catalog configured correctly using CATFILE.
If this is on Linux, using strace can help check which catalog file is
being used; you can also turn on debugging in a
CatalogManager.properties file containing the line
verbosity = 999
(thee file needs to be in your Java classpath).
There's also a BaseX pragma, (# db:catfile path/to/catalog.xml #) {
transform(...)
}
You need to turn off the BaseX internal parser.
Make sure that the resolver library and of course saxon are in your
class path.
You may need to add,
declare option db:catfile "path/relative/to/cwd/catalog.xml";
to your query.
Liam
--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsi...@le-tex.de, http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
Geschäftsführer / Managing Directors:
Gerrit Imsieke, Svea Jelonek, Thomas Schmidt
Re: [basex-talk] xslt:transform function not working with XML Catalog
Hi Liam,
Thanks for the reply and suggestions. Based on your suggestion I tried pragmas
and strace, and had another go at CatalogManager.properties, but they've not
had any effect. (I'm using Windows 10 but was able to run strace in Ubuntu via
WSL). This query:
try {
(# db:catfile 'schemas/catalog.xml' #)
(# db:intparse false #)
(# db:dtd true #)
(# db:chop false #)
{ xslt:transform('file.xml', 'stylesheet.xsl')//inlinegraphic }
} catch * { $err:description }
Produces the same error again due to the DTD not being available at the system
literal URI.
I did try setting verbosity 99 in a CatalogManager.properties file on the
classpath, but this did not produce any additional messages. I also tried
setting the same properties directly when launching BaseX this did not work
either. Specifically, I set the following system properties when launching
BaseX, and then used proc:property() in a query to confirm that these system
properties were in fact set.
'xml.catalog.verbosity': '99'
'xml.catalog.ignoreMissing': 'no'
'xml.catalog.catalog-class-name': 'org.apache.xml.resolver.Resolver'
'xml.catalog.files': 'schemas/catalog.xml'
xml-resolver-1.2.jar and Saxon are definitely on the classpath.
Thanks,
VIncent
_
Vincent M. Lizzi
Head of Information Standards | Taylor & Francis Group
vincent.li...@taylorandfrancis.com
Information Classification: General
From: Liam R. E. Quin
Sent: Wednesday, July 8, 2020 10:28 PM
To: Lizzi, Vincent ; BaseX
Subject: Re: [basex-talk] xslt:transform function not working with XML Catalog
On Wed, 2020-07-08 at 22:46 +, Lizzi, Vincent wrote:
> I've encountered a problem using xslt:transform in to transform some
> old XML that contains a DTD DOCTYPE system literal pointing to a non-
> working URI and also uses ENTITYREF attributes to refer to image
> files. I have the XML Catalog configured correctly using CATFILE.
If this is on Linux, using strace can help check which catalog file is
being used; you can also turn on debugging in a
CatalogManager.properties file containing the line
verbosity = 999
(thee file needs to be in your Java classpath).
There's also a BaseX pragma, (# db:catfile path/to/catalog.xml #) {
transform(...)
}
You need to turn off the BaseX internal parser.
Make sure that the resolver library and of course saxon are in your
class path.
You may need to add,
declare option db:catfile "path/relative/to/cwd/catalog.xml";
to your query.
Liam
--
Liam Quin,
https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations:
http://www.fromoldbooks.org
Re: [basex-talk] xslt:transform function not working with XML Catalog
On Wed, 2020-07-08 at 22:46 +, Lizzi, Vincent wrote:
> I've encountered a problem using xslt:transform in to transform some
> old XML that contains a DTD DOCTYPE system literal pointing to a non-
> working URI and also uses ENTITYREF attributes to refer to image
> files. I have the XML Catalog configured correctly using CATFILE.
If this is on Linux, using strace can help check which catalog file is
being used; you can also turn on debugging in a
CatalogManager.properties file containing the line
verbosity = 999
(thee file needs to be in your Java classpath).
There's also a BaseX pragma, (# db:catfile path/to/catalog.xml #) {
transform(...)
}
You need to turn off the BaseX internal parser.
Make sure that the resolver library and of course saxon are in your
class path.
You may need to add,
declare option db:catfile "path/relative/to/cwd/catalog.xml";
to your query.
Liam
--
Liam Quin, https://www.delightfulcomputing.com/
Available for XML/Document/Information Architecture/XSLT/
XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
[basex-talk] xslt:transform function not working with XML Catalog
I've encountered a problem using xslt:transform in to transform some old XML that contains a DTD DOCTYPE system literal pointing to a non-working URI and also uses ENTITYREF attributes to refer to image files. I have the XML Catalog configured correctly using CATFILE. The XSLT is using unparsed-entity-uri() to convert the ENTITYREF into a file name for an href attribute. I've tested the XSLT and the XML Catalog in oXygen and in XSpec, so I know they work. I've tried a few alternatives to get this to work in BaseX and have not arrived at a working solution. The BaseX setup uses BaseX 9.3.3, XML Resolver 1.2, and Saxon HE 9.9.1-7. Passing the XML directly to xslt:transform does not use the XML Catalog for parsing the XM. I've tried making the first parameter of xslt:transform a path to a XML file, an xs:anyURI pointing to the XML file, or string containing the XML. Each time the XML fails to parse due to the non-working URI in the system literal. When I change the system literal to a URI that works the transformation works and the unparsed-entity-uri() function produces the expected file name for the href attribute. I also tried parsing the XML using doc() or fetch:xml() first and then using the parsed XML as the first parameter of xslt:transform(). The doc() or fetch:xml does use the XML Catalog to parse the XML. However, unparsed-entity-uri() function produces an empty string because the DTD information is no longer available. Hoping to be able to spot the problem I looked through the BaseX code. XsltTransform is using CatalogWrapper to set a URIResolver, but is not setting an EntityResolver. SAXWrapper is using CatalogWrapper to set an EntityResolver before parsing XML. It looks like this should work, but it's not. The next alternative is to pre-process the XML using a regular expression to replace the non-working URI in the DOCTYPE system literal with a working URI prior to xslt:transform(). This works, but it seems like this is just working around a problem. Has anyone else encountered this problem and found a better solution? Thanks, Vincent __ Vincent M. Lizzi Head of Information Standards | Taylor & Francis Group 530 Walnut St., Suite 850, Philadelphia, PA 19106 E-Mail: vincent.li...@taylorandfrancis.com Phone: 215-606-4221 Web: www.tandfonline.com Taylor & Francis is a trading name of Informa UK Limited, registered in England under no. 1072954 "Everything should be made as simple as possible, but not simpler." Information Classification: General
Re: [basex-talk] Position of attributes using copy/modify
Hi Giuseppe, the attribute order cannot be enforced indeed. We can’t even guarantee that the attributes of a parsed document are returned in the same order when it’s serialized. This is due to the spec: attributes are treated as node properties with no particular order. A question in reverse: Why do you need attributes to be returned in a particular order? Ciao, Christian On Mon, Jul 6, 2020 at 7:57 PM Giuseppe G. A. Celano wrote: > > Hi, > > I know that the order of attributes in XML is not relevant, but I am > wondering whether there is a way to add an attribute as the last one using > copy/modify expression. The “as last” option seems not to work for attributes. > > Cheers, > Giuseppe
