Re: FW: resolveEntity and systemId question

[Jeff Crump <jc...@exceloncorp.com>]

What is the resolution to this problem? It's prohibiting me from doing
custom resolution.

jc



----- Original Message -----
From: "Chow, Crandall" <cc...@vignette.com>
To: "'Elena Litani'" <hl...@jtcsv.com>
Cc: <er...@locus.apache.org>; <xe...@xml.apache.org>
Sent: Wednesday, December 13, 2000 2:37 PM
Subject: RE: FW: resolveEntity and systemId question


> Elena,
>
> I'm looking at a "SYSTEM" identifier.  The XML recommendation is extremely
> vague about entity resolution.  But my understanding is:
>
> - if a PUBID is specified, try and resolve it to a resolved URI, else
> - if a SYSID is specified, try and resolve it to a resolved URI, else
> - assume the SYSID is the URI itself
>
> In the first two steps (resolving the PUBID or SYSID), the ID's
themeselves
> should not be modifed before passing them on to resolveEntity().  You
(mine,
> his) implementation of how to resolve entities should expect the passed in
> strings as just how they're coded.  If it's modified, the mappings will
not
> work.
>
> In the case of catalog file implementations, such as the one from
Arbortext,
> the PUBLIC keyword in a catalog file describes mappings for PUBID's; the
> SYSTEM keyword shows the mappings for SYSID's.  If you take a relative
SYSID
> and convert it to a fully qualified URI, as is being currently done in
> Xerces-J, then the mapping in the catalog file WILL NEVER WORK, since the
> mappings will only have the relative string in it, and the catalog file
will
> NEVER know what the fully qualified URI is since it may be being used from
> more than one host.
>
> By the way, I posted this twice on Xerces-J-Dev with no reply.  Is my post
> not showing up?
>
> Here's the text of my original post:
>
>
> Subject:  bug in DefaultEntityHandler.startReadingFromExternalEntity()?
>
> I've been playing with Arbortext's catalog entity resolver, and noticed
> there's a possible bug in 'DefaultEntityHandler.java' (Xerces-J 1.2.2).
The
> method is 'startReadingFromExternalEntity()'.  Line 749 has a call to
> 'expandSystemId()' before passing it on to a potential 'resolveEntity()'
on
> the following line.  I believe this is incorrect, since the system ID may
> now have the base directories and 'file:///' proto that the catalog
resolver
> may not be expecting.  Here's an example:
>
> CATALOG FILE
> ------------
> SYSTEM "fake.dtd" "docs/real.dtd"
>
> XML DOC
> -------
> <!DOCTYPE head SYSTEM "fake.dtd">
>
> Using a catalog entity resolver, this should work just fine, as the system
> ID "fake.dtd" is eventually mapped to "docs/real.dtd".  (By the way, it
> could also be mapped to a true URI, such as "file:///e:/docs/real.dtd",
but
> that's not a big deal in this example.)  In this case,
> DefaultEntityHandler.startReadingFromExternalEntity() will be called
during
> the parse to try and resolve the system ID "fake.dtd", before assuming
it's
> a straight URI.  The code as it sits will turn the ID "fake.dtd" into a
tru
> URI, such as "file:///e:/some_base/fake.dtd" before passing it onto the
> 'resolveEntity()' method of our entity resolver.  Obviously, there is no
map
> to this expanded system ID in the catalog, so the resolution will fail.
> This appears to not be the desired behavior, especially since the catalog
> author would never know the base directories prior to a given parse.
> Instead, I believe the code should appear similar to:
>
>         if (baseSystemId == null) {
>             ReaderState rs = (ReaderState) fReaderStack.peek();
>             baseSystemId = rs.systemId;
>         }
>         fSource = fResolver == null ? null :
> fResolver.resolveEntity(fPublicId, fSystemId);
>         if (fSource == null) {
>     fSystemId = expandSystemId(fSystemId, baseSystemId);
>             fSource = new InputSource(fSystemId);
>
> where the 'expandSystemId()' line is moved from line 749 into the 'if'
> statement at line 751.
>
> Can someone please confirm or reject this?  Who is the person in control
of
> this file in case a change is needed?  Thanks folks.
>
>
>
>   -crandall
>
> Crandall Chow (cchow@vignette.com)
> Vignette Corp.
> 901 South MoPac Expressway
> Building III
> Austin, Texas  78746-5776
> vox:  512-741-1055
> fax:  512-741-1400
>
>
> > -----Original Message-----
> > From: Elena Litani [mailto:hlitani@jtcsv.com]
> > Sent: Wednesday, December 13, 2000 12:26 PM
> > To: Chow, Crandall
> > Subject: Re: FW: resolveEntity and systemId question
> >
> >
> > > Is a relative path not allowed as a SYSID?  I can
> > understand an absolute
> > > path possibly needing the "file://" URI proto.  How would a
> > relative path be
> > > specified as a SYSID?
> >
> > I hope I understand your question correctly (I am pretty new to XML
> > after all :) ).
> > First, you can use smth like: SYSTEM "../../personal.dtd".
> >
> > Second, I guess you are looking for "PUBLIC" identifier? From
> > XML Specs:
> > "An XML processor attempting to retrieve the entity's content may use
> > the public identifier to try to generate an alternative URI reference.
> > If the processor is unable to do so, it must use the URI reference
> > specified in the system literal. Before a match is attempted, all
> > strings of white space in the public identifier must be normalized to
> > single space characters (#x20), and leading and trailing white space
> > must be removed." For public onces you can actually use smth like:
> > PUBLIC "foo" "foo.dtd"
> >
> > If I did not understand your question correctly, I suggest
> > you post this
> > question to mailing list and somebody will answer it.
> >
> > Regards,
> > Elena
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org