Since you are using a catalog, I would suggest turning on
catalog debugging
and seeing what is happening. Set the verbosity in the
CatalogManager.properties file to 3 or 4 and see if you can
see where it is
going wrong.
Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs sagehill.net
----- Original Message -----
From: <ppsdlsi.ua.es>
To: <docbook-appslists.oasis-open.org>
Sent: Friday, September 21, 2007 3:16 PM
Subject: Re: [docbook-apps] Non-validating Saxon
Thank you Bob for your response.
- I'm using Saxon 6.5.5 "as-it-is". I mean, I
dind't chnge the XML parser.
- Yes, I'm using the Apache resolver classes.
- No, I haven't modified any DTD.
The resolver seems to do its jobs OK.
It seems like:
- The XML catalog/resolver is rewriting URIs (PUBLIC or
SYSTEM) OK.
BUT onces the parsing process "branches" to a new
DTD reference, it cannot
find
next (3rd) "local" references, and the parser is
trying to find that module
in
the folder of the original DTD.
Example:
1) C:/lib/website/schema/website-full.dtd : this is the
parsing starting
point.
2) website-full.dtd references &docbook.dtd; entity
successfully resolved
at
(let say):
C:/lib/docbook/dtd/docbook.dtd
3) docbook.dtd makes a local reference to an entity
"x.mod" (present in the
same
folder as "docbook.dtd" by distribution). Then
Saxon issues an error
telling
something like it cannot access the file:
"C:/lib/website/schema/x.mod !!!
I would like to know if this is a catalog definition problem
(in which case
I
will re-build all the catalog hierarchy), or if it is
something different.
NOTE: if I prevent from resolving the reference in the step
2), that is to
say,
allowing saxon fetch the reference externally, it works
flawlessly.
Tahnk you very much in advance for your help.
Pedro
---- Mensaje Original ----
> Hi Pedro,
> While it may seem like Saxon is validating, it actually
is not validating
> your
elements against the DTD. All XML parsers must *read* the
DTD to find
declarations of entities that might be used in the document,
so that it can
substitute the text for any entity references it finds. So
if there is
DOCTYPE
reference to a DTD, the parser must be able to read the DTD.
There is no
way to
tell a parser to not look in the DTD if it finds a
reference to one. The
entity processing doesn't add much to the processing time
unless the DTD is
accessed over the net instead of locally.
>
> I think you should concentrate on fixing the DTD
references. Some more
details would help. Are you using an XML catalog and
resolver classes?
Xerces
parser? Have you modified the DTD files or locations?
>
> Bob Stayton
> Sagehill Enterprises
> DocBook Consulting
> bobssagehill.net
>
>
> ----- Original Message -----
> From: Pedro Pastor
> To: docbook-appslists.oasis-open.org
> Sent: Thursday, September 20, 2007 12:28 PM
> Subject: [docbook-apps] Non-validating Saxon
>
>
> How can I tell Saxon 6.5.5 not to validate the XML
files he is
> XSLT-processing?
>
>
>
> In addition to the extra execution time, I'm having
some mess with
> *.mod
references. For example, I'm using the website.dtd and Saxon
fails at
finding
the modules this dtd includes (extensions.mod for example).
This is very
strange
as long as the ENTITY PUBLIC reference is pointing locally
to
"extensions.mod"
(present in the same directory as website-full). If I insert
a public
http-path
and add this new entry in the catalog.xml it works.
>
> (Note: I=92m using Windows XP Pro=94  .
>
>
>
> Regards,
>
>
>
> Pedro
>
>
>
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.487 / Virus Database: 269.13.25/1018 -
Release Date:
> 19/09/2007
15:59
>
>
------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org
------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-apps-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-apps-helplists.oasis-open.org
|