xml-dev - RE: Parser Behaviour (serious- isSolved?)

["gopi" <gopi@aztecsoft.com>]

Hi all,
	I still wonder why Xerces developers didn't pitched in and tried to answer
this question?
If I have not mistaken, what Peter Murray's problem is, he doesn't want to
change his "each" xml file to make references to local directory DTD files.
When he is using it on laptop (offline), he wants to make reference to local
directory DTD's and exact DTD URL when online.
	If you take snapshot of recent Xerces Java from apache website and generate
javadoc.

	The package org.apache.xerces.readers has classes XCatalog and
XMLCatalogHandler.
They implement the Catalog specification available at URL
http://www.ccil.org/~cowan/XML/XCatalog.html.  The following line I have
quoted from
the URL
"XML Catalogs are Web resources (anything from local files on up) which
contain mappings from public identifiers to system identifiers (and
optionally mappings from system identifiers to other system identifiers),
plus references to other XML Catalogs."
	John Cawon had posted proposal draft 0.2 on xml-dev list sometime back
(according to the description given in URL). See the URL for more info

	So, what we need to do is have different "catalog files" when using online
and offline.  Use these catalog files in your application.  When you want to
use offline, use catalog file which maps these external DTD references (to
say w3c website) to your local DTD copy.  If you want to use these exact
external references use catalog file without these mappings.  The problem
will be solved. [I hope so :-)].
	I was just about to send the mail, I got mail from Bruce. I guess this
anwers ur query.

	XCatalog catalog = new XCatalog();
	catalog.loadCatalog(new InputSource(new
FileInputStream("d:\\xml\\catalog.xml")));
	DOMParser parser = new DOMParser();
	parser.setEntityResolver(catalog);

	// go ahead with your application specific calls. Njoy :-)
	FYI:  XCatalog extends from XMLCatalogHandler.  XMLCatalogHandler
implements EntityResolver.

	I don't know how to handle with other parsers like XP?
regards,
Gopinath M.R.
Software Engineer,
Aztec software and technology services (P) Ltd ( www.aztec.soft.net )
Bangalore -560078
email : gopi@aztecsoft.com <mailto:gopi@aztecsoft.com>
gopinathmr@bigfoot.com <mailto:gopinathmr@bigfoot.com>
"XML data is not slow, the implementation is making it slow"

-----Original Message-----
From: owner-xml-dev@xml.org [mailto:owner-xml-dev@xml.org]On Behalf Of
Simon St.Laurent
Sent: Tuesday, April 04, 2000 2:08 AM
To: xml-dev@xml.org
Subject: RE: Parser Behaviour (serious)


At 08:48 AM 4/3/00 +0100, Peter Murray-Rust wrote:
>So my summary is:
>	-[...lots...]
>	- We have a serious problem.
>
>My invitation is for someone or some group to describe exhaustively what
>the problem(s) actually are. It might be that we can then all agree on
>appropriate behaviour under every combination.

I'm not sure if it will help enough, but some of us on SML-DEV have been
looking at these problems from a different direction.  We presented this
'Common XML' at XTech  - see
http://www.docuverse.com/smldev/xtech2000/cxml.html or
http://www.docuverse.com/smldev/xtech2000/ for more info on SML-DEV work in
general.

We've all been rather busy, but we're finally getting some text together.
This is rough material, which I'm hoping will see substantial revision in
the next few weeks or months, but I think the basic concepts (starting with
a simple core, then building out, primarily) come through.

Intro: http://www.egroups.com/message/sml-dev/2771
Core: http://www.egroups.com/message/sml-dev/2983
Extending: http://www.egroups.com/message/sml-dev/2985

These are preliminary and don't yet represent anything like a consensus
vision, or at least I have no grounds on which to claim that they do.

I'd like to see interoperability (i14y?) hammered out so we can stop
talking about these issues so often, but I realize that may well be
difficult.

Comments and suggestions are welcome, though I don't have any time in my
schedule this week for flame wars.  Maybe next week!


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************