You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tal Dayan <ta...@zapta.com> on 2001/11/13 20:14:05 UTC
RE: [digester] relative patterns
Hello,
It looks like Digester accepts built in rules only with absolute patterns
such as
digester.addSomeRule("aa"
digester.addSomeRule("aa/bb/cc"
digester.addSomeRule("aa/bb"
which requires some work when moving things around the hierarchy.
How about adding support for relative patterns like (very rough syntax):
digester.setBase("/aa")
digester.addSomeRule("." --> /aa
digester.addSomeRule("./bb/cc" --> /aa/bb/cc
digester.addSomeRule("!" --> /aa/bb/cc (the previous path)
digester.addSomeRule("!/../dd" --> /aa/bb/dd
This will affect only the creation of the rules and will not add overhead to
the actual parsing of the XML document.
Tal
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] relative patterns
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 13 Nov 2001, Tal Dayan wrote:
> Date: Tue, 13 Nov 2001 18:59:31 -0800
> From: Tal Dayan <ta...@zapta.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: RE: [digester] relative patterns
>
> Thanks, I will take a look, I am still finding my way in the features
> provided by the
> current version of Digester.
>
> The case I had in mind was not where the same set of rules is used several
> times
> but where several rules are used with the same path.
>
> As for using '*/b' instead of '/a/b', I presume this changes the semantic of
> the rule, right ?
It doesn't change the semantic of what the rule *does*. It only changes
the semantic of when the rule is *matched*.
>
> Tal
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] relative patterns
Posted by Tal Dayan <ta...@zapta.com>.
Thanks, I will take a look, I am still finding my way in the features
provided by the
current version of Digester.
The case I had in mind was not where the same set of rules is used several
times
but where several rules are used with the same path.
As for using '*/b' instead of '/a/b', I presume this changes the semantic of
the rule, right ?
Tal
> -----Original Message-----
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: Tuesday, November 13, 2001 11:34 AM
> To: Jakarta Commons Developers List
> Subject: RE: [digester] relative patterns
>
>
> There are two things you should take a look at in the documentation:
>
> * Using the "*" in a matching pattern ("*/a" matches <a> no matter
> where it is nested)
>
> * The ability to write your own implementation of matching by defining
> a "Rules" implementation.
>
> I would not personally implement your "the previous path" pattern -- it
> makes setting up the rules very fragile if you switch the order of your
> addRule() statements around. But you can do it yourself.
>
> For re-use of existing sets of rules, check out the RuleSet class as well.
> Tomcat makes good use of this mechanism, because there are multiple places
> at which the same set of rules should be applied (but with different
> prefixes to the matching patterns).
>
> Craig
>
>
> On Tue, 13 Nov 2001, Tal Dayan wrote:
>
> > Date: Tue, 13 Nov 2001 11:14:05 -0800
> > From: Tal Dayan <ta...@zapta.com>
> > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: RE: [digester] relative patterns
> >
> > Hello,
> >
> >
> > It looks like Digester accepts built in rules only with
> absolute patterns
> > such as
> >
> > digester.addSomeRule("aa"
> > digester.addSomeRule("aa/bb/cc"
> > digester.addSomeRule("aa/bb"
> >
> > which requires some work when moving things around the hierarchy.
> >
> > How about adding support for relative patterns like (very rough syntax):
> >
> > digester.setBase("/aa")
> > digester.addSomeRule("." --> /aa
> > digester.addSomeRule("./bb/cc" --> /aa/bb/cc
> > digester.addSomeRule("!" --> /aa/bb/cc (the
> previous path)
> > digester.addSomeRule("!/../dd" --> /aa/bb/dd
> >
> > This will affect only the creation of the rules and will not
> add overhead to
> > the actual parsing of the XML document.
> >
> > Tal
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [digester] using non URL'ed DTD's
Posted by ma...@tumbleweed.com.
>From the Javadocs for java.lang.Error:
"An Error is a subclass of Throwable that indicates serious problems that a
reasonable application should not try to catch."
So, no, Error is not the right thing to throw, because presumably it's
something you want to catch and handle elsewhere in your app. You'll want to
throw an exception of a class derived from java.lang.Exception instead.
--
Martin Cooper
----- Original Message -----
From: "Tal Dayan" <ta...@zapta.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Wednesday, November 14, 2001 10:04 AM
Subject: RE: [digester] using non URL'ed DTD's
> >
> > > Now, how do I abort the parsing and throw an exception if the
validation
> > > (using the DTD) fails ? Currently the parsing just continues as usual
so
> > > when the parsing ends, the application does not know if the XML
> > document was
> > > valid or not.
> > >
> >
> > Normally, Digester just logs the error messages and goes on. If you
want
> > it to abort the parse instead, you need to implement a SAX ErrorHandler
> > that actually throws exeptions from its methods, and then call
> > digester.setErrorHandler() before the parse to install it.
>
> Thanks. It worked as advertised. We abort the parsing by throwing an
> java.lang.Error from the
> Error Handler. Is this is the right way to do so ?
>
> Also, Digester prints the entire stack trace of the SAXParseException
> excpetion before it calls our handler, even when the debugging level is
set
> to zero. We don't want to turn off the logging but the dump of the entire
> stack just to report a syntax error in the XML document is more than our
> users need.
>
> How about not logging or dumping the exception if it is passed to a
> customized handler anyway ? Or, we can have a flag when setting the
handler
> to indicate if Digester should report the exceptions as well.
>
>
> > > And next step, how can I check if the public ID of the DTD in the XML
> > > document was the expected one (for which we set a local
> > resolver using the
> > > register() method) ?
> > >
> >
> > In other words, you want to ensure that *only* one of your registered
> > public IDs is selected? In the plans is a setEntityResolver() that will
> > work like setErrorHandler() does, and lets you install your own. In the
> > mean time, you could subclass Digester and override the resolveEntity()
> > method. If the first argument is registered, go ahead and call the
> > superclass resolveEntity() method; if it's not, throw an exception.
>
> We integrated Jeff's Doctype Changer in our Digester wrapper class and it
> works great. You can
> force any DTD that you want, even if there is not DOCTYPE at all. The DTD
> you force can be fixed,
> or based on the original DOCTYPE and you can also save the properties of
the
> original DOCTYPE to verified that the user specified a valid DTD. This is
> kind of functionality that I would expect to find in the XML parsers
> themselves but I don't think they provide it.
>
> Tal
>
> >
> > > Thanks,
> > >
> > > Tal
> > >
> >
> > Craig
> >
> >
> > > > -----Original Message-----
> > > > From: Louis Tribble [mailto:louis.tribble@webgain.com]
> > > > Sent: Tuesday, November 13, 2001 8:19 PM
> > > > To: Jakarta Commons Developers List
> > > > Subject: Re: [digester] using non URL'ed DTD's
> > > >
> > > >
> > > > > We are still not able to use a DTD for validation because our
> > > > DTD file has a
> > > > > path that
> > > > > is not acceptable by Digester and/or the underlying XML parser
> > > > (the URL is
> > > > > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> > > > > everything).
> > > >
> > > > >From RFC 1738:
> > > > > A file URL takes the form:
> > > > >
> > > > > file://<host>/<path>
> > > > >
> > > > > <snip>
> > > > > As a special case, <host> can be the string "localhost" or the
> > > > empty string; this
> > > > > is interpreted as `the machine from which the URL is being
> > interpreted'.
> > > >
> > > > With two slashes, "d:" is a host name. With three slashes, the
> > > > URL should be interpreted
> > > > correctly. By the grace of many URL parsers, one slash sometimes
> > > > works too.
> > > >
> > > > Louis Tribble
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 14 Nov 2001, Tal Dayan wrote:
> Date: Wed, 14 Nov 2001 10:04:16 -0800
> From: Tal Dayan <ta...@zapta.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: RE: [digester] using non URL'ed DTD's
>
> >
> > > Now, how do I abort the parsing and throw an exception if the validation
> > > (using the DTD) fails ? Currently the parsing just continues as usual so
> > > when the parsing ends, the application does not know if the XML
> > document was
> > > valid or not.
> > >
> >
> > Normally, Digester just logs the error messages and goes on. If you want
> > it to abort the parse instead, you need to implement a SAX ErrorHandler
> > that actually throws exeptions from its methods, and then call
> > digester.setErrorHandler() before the parse to install it.
>
> Thanks. It worked as advertised. We abort the parsing by throwing an
> java.lang.Error from the
> Error Handler. Is this is the right way to do so ?
>
That works ... or you could throw a SAXException (or a subclass of it) if
you wanted the error to be more specific. This would ultimately get
rethrown from digester.parse() back to the application, so you could
throw (for example) a SAXParseException that includes the location of the
actual error.
> Also, Digester prints the entire stack trace of the SAXParseException
> excpetion before it calls our handler, even when the debugging level is set
> to zero. We don't want to turn off the logging but the dump of the entire
> stack just to report a syntax error in the XML document is more than our
> users need.
>
> How about not logging or dumping the exception if it is passed to a
> customized handler anyway ? Or, we can have a flag when setting the handler
> to indicate if Digester should report the exceptions as well.
>
That makes sense. In the mean time, you can always subclass and override.
>
> > > And next step, how can I check if the public ID of the DTD in the XML
> > > document was the expected one (for which we set a local
> > resolver using the
> > > register() method) ?
> > >
> >
> > In other words, you want to ensure that *only* one of your registered
> > public IDs is selected? In the plans is a setEntityResolver() that will
> > work like setErrorHandler() does, and lets you install your own. In the
> > mean time, you could subclass Digester and override the resolveEntity()
> > method. If the first argument is registered, go ahead and call the
> > superclass resolveEntity() method; if it's not, throw an exception.
>
> We integrated Jeff's Doctype Changer in our Digester wrapper class and it
> works great. You can
> force any DTD that you want, even if there is not DOCTYPE at all. The DTD
> you force can be fixed,
> or based on the original DOCTYPE and you can also save the properties of the
> original DOCTYPE to verified that the user specified a valid DTD. This is
> kind of functionality that I would expect to find in the XML parsers
> themselves but I don't think they provide it.
>
> Tal
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by Tal Dayan <ta...@zapta.com>.
>
> > Now, how do I abort the parsing and throw an exception if the validation
> > (using the DTD) fails ? Currently the parsing just continues as usual so
> > when the parsing ends, the application does not know if the XML
> document was
> > valid or not.
> >
>
> Normally, Digester just logs the error messages and goes on. If you want
> it to abort the parse instead, you need to implement a SAX ErrorHandler
> that actually throws exeptions from its methods, and then call
> digester.setErrorHandler() before the parse to install it.
Thanks. It worked as advertised. We abort the parsing by throwing an
java.lang.Error from the
Error Handler. Is this is the right way to do so ?
Also, Digester prints the entire stack trace of the SAXParseException
excpetion before it calls our handler, even when the debugging level is set
to zero. We don't want to turn off the logging but the dump of the entire
stack just to report a syntax error in the XML document is more than our
users need.
How about not logging or dumping the exception if it is passed to a
customized handler anyway ? Or, we can have a flag when setting the handler
to indicate if Digester should report the exceptions as well.
> > And next step, how can I check if the public ID of the DTD in the XML
> > document was the expected one (for which we set a local
> resolver using the
> > register() method) ?
> >
>
> In other words, you want to ensure that *only* one of your registered
> public IDs is selected? In the plans is a setEntityResolver() that will
> work like setErrorHandler() does, and lets you install your own. In the
> mean time, you could subclass Digester and override the resolveEntity()
> method. If the first argument is registered, go ahead and call the
> superclass resolveEntity() method; if it's not, throw an exception.
We integrated Jeff's Doctype Changer in our Digester wrapper class and it
works great. You can
force any DTD that you want, even if there is not DOCTYPE at all. The DTD
you force can be fixed,
or based on the original DOCTYPE and you can also save the properties of the
original DOCTYPE to verified that the user specified a valid DTD. This is
kind of functionality that I would expect to find in the XML parsers
themselves but I don't think they provide it.
Tal
>
> > Thanks,
> >
> > Tal
> >
>
> Craig
>
>
> > > -----Original Message-----
> > > From: Louis Tribble [mailto:louis.tribble@webgain.com]
> > > Sent: Tuesday, November 13, 2001 8:19 PM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [digester] using non URL'ed DTD's
> > >
> > >
> > > > We are still not able to use a DTD for validation because our
> > > DTD file has a
> > > > path that
> > > > is not acceptable by Digester and/or the underlying XML parser
> > > (the URL is
> > > > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> > > > everything).
> > >
> > > >From RFC 1738:
> > > > A file URL takes the form:
> > > >
> > > > file://<host>/<path>
> > > >
> > > > <snip>
> > > > As a special case, <host> can be the string "localhost" or the
> > > empty string; this
> > > > is interpreted as `the machine from which the URL is being
> interpreted'.
> > >
> > > With two slashes, "d:" is a host name. With three slashes, the
> > > URL should be interpreted
> > > correctly. By the grace of many URL parsers, one slash sometimes
> > > works too.
> > >
> > > Louis Tribble
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 13 Nov 2001, Tal Dayan wrote:
> Date: Tue, 13 Nov 2001 23:01:10 -0800
> From: Tal Dayan <ta...@zapta.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> Louis Tribble <lo...@webgain.com>
> Subject: RE: [digester] using non URL'ed DTD's
>
> Thanks. This works. The DTD file is now recognized and I can see printout of
> exceptions if the
> XML document does not match the DTD.
>
Cool.
> Now, how do I abort the parsing and throw an exception if the validation
> (using the DTD) fails ? Currently the parsing just continues as usual so
> when the parsing ends, the application does not know if the XML document was
> valid or not.
>
Normally, Digester just logs the error messages and goes on. If you want
it to abort the parse instead, you need to implement a SAX ErrorHandler
that actually throws exeptions from its methods, and then call
digester.setErrorHandler() before the parse to install it.
> And next step, how can I check if the public ID of the DTD in the XML
> document was the expected one (for which we set a local resolver using the
> register() method) ?
>
In other words, you want to ensure that *only* one of your registered
public IDs is selected? In the plans is a setEntityResolver() that will
work like setErrorHandler() does, and lets you install your own. In the
mean time, you could subclass Digester and override the resolveEntity()
method. If the first argument is registered, go ahead and call the
superclass resolveEntity() method; if it's not, throw an exception.
> Thanks,
>
> Tal
>
Craig
> > -----Original Message-----
> > From: Louis Tribble [mailto:louis.tribble@webgain.com]
> > Sent: Tuesday, November 13, 2001 8:19 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [digester] using non URL'ed DTD's
> >
> >
> > > We are still not able to use a DTD for validation because our
> > DTD file has a
> > > path that
> > > is not acceptable by Digester and/or the underlying XML parser
> > (the URL is
> > > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> > > everything).
> >
> > >From RFC 1738:
> > > A file URL takes the form:
> > >
> > > file://<host>/<path>
> > >
> > > <snip>
> > > As a special case, <host> can be the string "localhost" or the
> > empty string; this
> > > is interpreted as `the machine from which the URL is being interpreted'.
> >
> > With two slashes, "d:" is a host name. With three slashes, the
> > URL should be interpreted
> > correctly. By the grace of many URL parsers, one slash sometimes
> > works too.
> >
> > Louis Tribble
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by Tal Dayan <ta...@zapta.com>.
Thanks. This works. The DTD file is now recognized and I can see printout of
exceptions if the
XML document does not match the DTD.
Now, how do I abort the parsing and throw an exception if the validation
(using the DTD) fails ? Currently the parsing just continues as usual so
when the parsing ends, the application does not know if the XML document was
valid or not.
And next step, how can I check if the public ID of the DTD in the XML
document was the expected one (for which we set a local resolver using the
register() method) ?
Thanks,
Tal
> -----Original Message-----
> From: Louis Tribble [mailto:louis.tribble@webgain.com]
> Sent: Tuesday, November 13, 2001 8:19 PM
> To: Jakarta Commons Developers List
> Subject: Re: [digester] using non URL'ed DTD's
>
>
> > We are still not able to use a DTD for validation because our
> DTD file has a
> > path that
> > is not acceptable by Digester and/or the underlying XML parser
> (the URL is
> > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> > everything).
>
> >From RFC 1738:
> > A file URL takes the form:
> >
> > file://<host>/<path>
> >
> > <snip>
> > As a special case, <host> can be the string "localhost" or the
> empty string; this
> > is interpreted as `the machine from which the URL is being interpreted'.
>
> With two slashes, "d:" is a host name. With three slashes, the
> URL should be interpreted
> correctly. By the grace of many URL parsers, one slash sometimes
> works too.
>
> Louis Tribble
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [digester] using non URL'ed DTD's
Posted by Louis Tribble <lo...@webgain.com>.
> We are still not able to use a DTD for validation because our DTD file has a
> path that
> is not acceptable by Digester and/or the underlying XML parser (the URL is
> 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> everything).
>From RFC 1738:
> A file URL takes the form:
>
> file://<host>/<path>
>
> <snip>
> As a special case, <host> can be the string "localhost" or the empty string; this
> is interpreted as `the machine from which the URL is being interpreted'.
With two slashes, "d:" is a host name. With three slashes, the URL should be interpreted
correctly. By the grace of many URL parsers, one slash sometimes works too.
Louis Tribble
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by Tal Dayan <ta...@zapta.com>.
Any objection from the maintainers of Digester for adding a register(...,
InputStream) method ?
Internally, the digester converts anyway the URL to an InputStream. This
will allow to accept a DTD from any source (memory, database, etc) and not
just a URL'ed resource. This is supported anyway by the underlying parsers.
I may provide the code if needed.
Tal
> -----Original Message-----
> From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig
> R. McClanahan
> Sent: Tuesday, November 13, 2001 6:56 PM
> To: Jakarta Commons Developers List
> Subject: RE: [digester] using non URL'ed DTD's
>
>
>
>
> On Tue, 13 Nov 2001, Tal Dayan wrote:
>
> > Date: Tue, 13 Nov 2001 18:59:30 -0800
> > From: Tal Dayan <ta...@zapta.com>
> > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: RE: [digester] using non URL'ed DTD's
> >
> > Hello,
> >
> > We are still not able to use a DTD for validation because our
> DTD file has a
> > path that
> > is not acceptable by Digester and/or the underlying XML parser
> (the URL is
> > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> > everything).
>
> Digester couldn't care less, as long as the JDK doesn't throw
> MalformedURLException. If your parser chokes on this, it's time to get a
> better parser :-). Or, figure out what your parser *will* accept for
> Windows-based file paths. That's up to whatever parser you are using, not
> Digester.
>
> > Actually, this is a more general issue in cases where the DTD
> > can not be referred to by a URL (e.g., when it is taken
> directly from a data
> > base).
> >
> > My suggestion is to add another registration method that
> accepts a Reader
> > instead of the URL. This way the DTD can be retrieved from
> file, in memory
> > cache buffer, etc.
> >
>
> Both JAXP/1.1 and Xerces 1.4.3 work for me, on both Windows and Unix.
>
> > Thanks,
> >
> > Tal
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 13 Nov 2001, Tal Dayan wrote:
> Date: Tue, 13 Nov 2001 18:59:30 -0800
> From: Tal Dayan <ta...@zapta.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: RE: [digester] using non URL'ed DTD's
>
> Hello,
>
> We are still not able to use a DTD for validation because our DTD file has a
> path that
> is not acceptable by Digester and/or the underlying XML parser (the URL is
> 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> everything).
Digester couldn't care less, as long as the JDK doesn't throw
MalformedURLException. If your parser chokes on this, it's time to get a
better parser :-). Or, figure out what your parser *will* accept for
Windows-based file paths. That's up to whatever parser you are using, not
Digester.
> Actually, this is a more general issue in cases where the DTD
> can not be referred to by a URL (e.g., when it is taken directly from a data
> base).
>
> My suggestion is to add another registration method that accepts a Reader
> instead of the URL. This way the DTD can be retrieved from file, in memory
> cache buffer, etc.
>
Both JAXP/1.1 and Xerces 1.4.3 work for me, on both Windows and Unix.
> Thanks,
>
> Tal
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by Michael Smith <mi...@iammichael.org>.
file://d:/a/b/c.dtd isn't a valid URL.
Section 3.10 of RFC 1738 [ http://www.faqs.org/rfcs/rfc1738.html ]:
A file URL takes the form:
file://<host>/<path>
where <host> is the fully qualified domain name of the system on
which the <path> is accessible, and <path> is a hierarchical
directory path of the form <directory>/<directory>/.../<name>.
[snip]
As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted'.
By specifying file://d:/a/b/c.dtd, you are specifing that "d:" is the
host rather than part of the actual file path.
Add an extra / in there, and things should work ok:
file:///d:/a/b/c.dtd
in this case the "empty string" between the second and third / implies
the file is on the local host.
regards,
michael
> -----Original Message-----
> From: Tal Dayan [mailto:tal@zapta.com]
> Sent: Tuesday, November 13, 2001 10:00 PM
> To: Jakarta Commons Developers List
> Subject: RE: [digester] using non URL'ed DTD's
>
>
> Hello,
>
> We are still not able to use a DTD for validation because our
> DTD file has a
> path that
> is not acceptable by Digester and/or the underlying XML
> parser (the URL is
> 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
> everything). Actually, this is a more general issue in cases
> where the DTD
> can not be referred to by a URL (e.g., when it is taken
> directly from a data
> base).
>
> My suggestion is to add another registration method that
> accepts a Reader
> instead of the URL. This way the DTD can be retrieved from
> file, in memory
> cache buffer, etc.
>
> Thanks,
>
> Tal
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] using non URL'ed DTD's
Posted by Tal Dayan <ta...@zapta.com>.
Hello,
We are still not able to use a DTD for validation because our DTD file has a
path that
is not acceptable by Digester and/or the underlying XML parser (the URL is
'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses
everything). Actually, this is a more general issue in cases where the DTD
can not be referred to by a URL (e.g., when it is taken directly from a data
base).
My suggestion is to add another registration method that accepts a Reader
instead of the URL. This way the DTD can be retrieved from file, in memory
cache buffer, etc.
Thanks,
Tal
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [digester] relative patterns
Posted by "Craig R. McClanahan" <cr...@apache.org>.
There are two things you should take a look at in the documentation:
* Using the "*" in a matching pattern ("*/a" matches <a> no matter
where it is nested)
* The ability to write your own implementation of matching by defining
a "Rules" implementation.
I would not personally implement your "the previous path" pattern -- it
makes setting up the rules very fragile if you switch the order of your
addRule() statements around. But you can do it yourself.
For re-use of existing sets of rules, check out the RuleSet class as well.
Tomcat makes good use of this mechanism, because there are multiple places
at which the same set of rules should be applied (but with different
prefixes to the matching patterns).
Craig
On Tue, 13 Nov 2001, Tal Dayan wrote:
> Date: Tue, 13 Nov 2001 11:14:05 -0800
> From: Tal Dayan <ta...@zapta.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: RE: [digester] relative patterns
>
> Hello,
>
>
> It looks like Digester accepts built in rules only with absolute patterns
> such as
>
> digester.addSomeRule("aa"
> digester.addSomeRule("aa/bb/cc"
> digester.addSomeRule("aa/bb"
>
> which requires some work when moving things around the hierarchy.
>
> How about adding support for relative patterns like (very rough syntax):
>
> digester.setBase("/aa")
> digester.addSomeRule("." --> /aa
> digester.addSomeRule("./bb/cc" --> /aa/bb/cc
> digester.addSomeRule("!" --> /aa/bb/cc (the previous path)
> digester.addSomeRule("!/../dd" --> /aa/bb/dd
>
> This will affect only the creation of the rules and will not add overhead to
> the actual parsing of the XML document.
>
> Tal
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>