Re: Shortsightedness and DTDs

[Dean Roddey <dr...@charmedquark.com>]

YOu wouldn't use the root element name. You'd use a PUBLIC id, like:

<DOCTYPE Foo PUBLIC "C:\SomeDefaultSysId" "TheBazDTD">

Your entity resolver will watch for the public "TheBazDTD" id, or whatever
others you want, and trigger your lookup based on that. You can certainly
also allow for some external configuration of your lookup table, which
allows the user on the particular host to provide the mappings.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"It takes two buttocks to make friction"
    - African Proverb


----- Original Message -----
From: "Corbett, Keith" <km...@netgen.com>
To: <so...@usa.net>
Cc: <xe...@xml.apache.org>
Sent: Thursday, August 31, 2000 2:37 PM
Subject: RE: Shortsightedness and DTDs


> Thanks for the tip. I think I see how to implement a a specialized
> EntityResolver, so I can create a basic catalog mechanism to resolve
PUBLIC
> IDs or translate SYSTEM IDs.
>
> Q: Can I redirect the DOM parser to the DTD based on the document type? If
> the parser sees <!DOCTYPE foo> I want to look up the DTD in my catalog
with
> "foo" as my lookup key and return the system identifier (URI or pathname)
to
> the parser. I want to do this regardless of whether any IDs are specified.
>
> /kmc
>
>
> > -----Original Message-----
> > From: Dean Roddey [mailto:droddey@charmedquark.com]
> > Sent: Tuesday, August 29, 2000 9:40 PM
> > To: xerces-c-dev@xml.apache.org; sosedada@usa.net
> > Subject: Re: Shortsightedness and DTDs
> >
> >
> > If you are providing a program to process the XML, then hard
> > code the DTD
> > into the program, so that its always there. Or, if there is
> > not a fixed set
> > of DTDs, your program can use an entity resolver. Have the users put a
> > "PUBLIC" id into the XML file, instead of a "SYSTEM" id. Then
> > have them give
> > you a search path to DTDs (or set up an environment variable
> > whose value is
> > a search path.) When your entity resolver sees the logical
> > public ids, it
> > will translate that to a real DTD name and search the search
> > path and find
> > it.
> >
> > --------------------------
> > Dean Roddey
> > The CIDLib C++ Frameworks
> > Charmed Quark Software
> > droddey@charmedquark.com
> > http://www.charmedquark.com
> >
> > "It takes two buttocks to make friction"
> >     - African Proverb
> >
> >
> > ----- Original Message -----
> > From: "Thomas Matelich" <tm...@zetec.com>
> > To: <xe...@xml.apache.org>
> > Sent: Tuesday, August 29, 2000 1:19 PM
> > Subject: Shortsightedness and DTDs
> >
> >
> > > Hello all,
> > >
> > >     I'm using xml files as a convenient way to store information in
> > > text.  No internet connection required by my system.  So, I'm using
> > > local DTD's.  People do want to be able to trade their xml
> > files around
> > > though.  Somehow, the testers and I hadn't run into the
> > problem where
> > > the file path to the DTD isn't the same on both machines,
> > till today.
> > > So I can think of a few options to get out of this:
> > >
> > > 1)  Remove the DTD's  --  I hope it doesn't come to this)
> > >
> > > 2)  Modify the xml files on disk  --  Wouldn't be too
> > complicated since
> > > I create the files I read, just slow and ugly.
> > >
> > > 3)  Recover from the failed parse and try again  -- Is it
> > possible to
> > > have DOMParser completely ignore the DTD file?
> > >
> > > 4)  Write my own InputSource that fixes it  --  This is
> > like 2).  How
> > > hard would this be?
> > >
> > > 5) ???
> > >
> > > Are there any other options?  Some sort of environment
> > variable for the
> > > path?  Please help.
> > >
> > > Thanks,
> > > Tom
> > >
> > > --
> > > Thomas O Matelich
> > > Senior Software Designer
> > > Zetec, Inc.
> > > sosedada@usa.net
> > > tmatelich@zetec.com
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>