XML Namespace Catalog proposal 2nd edition

[Jonathan Borden <jborden@mediaone.net>]

I would like to thank everyone who has responded both on and off the list
regarding http://lists.xml.org/archives/xml-dev/200012/msg00749.html

Most of the suggestions by essentially all whom have responded are excellent
and I have incorporated most of them into a new version of the now named XML
Namespace Catalog proposal still located at:

http://www.openhealth.org/XMLCatalog/


After due consideration, I believe it is best not to overload current
HTML/XHTML tags with an entirely new behavior. I introduce a new element
termed "resource" on which the XLink is defined.

	Reasons:

1) overloading the <link> or <a> tags causes conflict with the "href"
attribute (it is too similar to the "xlink:href" attribute).

	The new "resource" element may be included either as:
	a) part of the "head" element (in %Head.opts")
	b) within the "body" (in "%Misc.class")

2) This effectively incorporates the functionality of Tim Bray's proposal.

I think that instead of overloading the semantics of either the HTML link or
div tags, a new tag is in order (and not a big deal).

The new DTD is extended from XHTML Basic 1.0 and is located at:
http://www.openhealth.org/XMLCatalog/xcat-xhtml.dtd

Such a "resource" element may also be easily included within an XSD
appinfo/documentation tag.

Regarding the possibility of a single vs. multiple XNC catalogs, the
intention is for a SAX entity resolver to suck in an XML Namespace Catalog
and resolve off this. One could certainly provide an alternate/local catalog
from which a custom entity resolver would resolve. This is an implementation
issue somewhat orthogonal to the XML Namespace Catalog Format itself.

Keep the comments coming :-)

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org