Hey Michael.
I'll look into that for sure as like you said it probably allows me to
apply the entities more easily.
But I don't think that allows me to apply the DOCTYPE only to xincluded
documents only when the the xinclude parse type is xml. Thats the real
problem I am facing.
Imagine a document like:
<book>
<xi:include
xmlns:xi="http://www.w3.org/2001/XInclude";
href="Book_Info.xml" />
<programlisting>
<xi:include
xmlns:xi="http://www.w3.org/2001/XInclude";
href="exampl.xml"
parse="text"/>
</programlisting>
</book>
The problem is that in the first XInclude I need the entities injected;
in the second they should not.
On Tue, 2010-08-17 at 15:29 -0400, Michael Glavassevich wrote:
> Hi Steve,
>
> Have you tried EntityResolver2.getExternalSubset() [1]? This was
> designed for injecting a DTD external subset into an XML document
> which doesn't have one. It should be more reliable than the method
> you're using.
>
> Thanks.
>
> [1]
> http://xerces.apache.org/xerces2-j/javadocs/api/org/xml/sax/ext/EntityResolver2.html#getExternalSubset%28java.lang.String,%20java.lang.String%29
>
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrgla...@ca.ibm.com
> E-mail: mrgla...@apache.org
>
> Steve Ebersole <steven.ebers...@gmail.com> wrote on 08/17/2010
> 12:55:13 PM:
>
> > I have a requirement to inject custom DOCTYPE entity declarations
> into
> > xincluded documents. Currently I am using an
> org.xml.sax.EntityResolver
> > to accomplish this. When my EntityResolver[1] understands a request
> it
> > creates and returns a special InputSource[2]. This however gives me
> > problems with an xinclude that is an xml file but that has specified
> > parse="text". The EntityResolver has no idea about that fact and so
> it
> > does these injections anyway (these are docbook documentation
> examples,
> > the end result being that the "injected" doctype ends up in the
> examples
> > as well).
> >
> > Searching around led me to find
> > org.apache.xerces.xinclude.XIncludeHandler which *seems* like it
> would
> > be a better place to tie in this processing. So my first question
> is
> > whether that is the case; am I barking up the right tree here?
> >
> > Assuming so, I am having difficulty understanding how to tel Xerces
> to
> > use my XIncludeHander instead of its built-in one. All the examples
> I
> > have seen use a configuraton to completely set up the pipeline
> > (org.apache.xerces.parsers.XIncludeAwareParserConfiguration).
> However
> > all the examples I saw do this from the command line by specifying
> -D to
> > name this configuration. I do not have that option (easily). So is
> > there another way to define the pipeline to use? Ideally, is there
> a
> > way to just alter one part of the pipeline? I have seen the
> > "http://apache.org/xml/properties/internal/xinclude-handler";
> setting,
> > but I have no idea how to leverage it.
> >
> > Thanks.
> >
> > [1]
> > http://github.com/sebersole/jdocbook-core/blob/master/src/main/java/
> > org/jboss/jdocbook/xslt/XIncludeEntityResolver.java
> > [2]
> > http://github.com/sebersole/jdocbook-core/blob/master/src/main/java/
> > org/jboss/jdocbook/util/FileUtils.java
> >
> >
> > --
> > Steve Ebersole <st...@hibernate.org>
> > http://hibernate.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
> > For additional commands, e-mail: j-users-h...@xerces.apache.org
>
>
--
Steve Ebersole <st...@hibernate.org>
http://hibernate.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org
