XML Namespace Catalog

Date:      Sun, 31 Dec 2000 13:21:58 -0500
From:      Jonathan Borden <jborden@mediaone.net>
To:        XML-Dev Mailing list <xml-dev@xml.org>
Cc: Dan Brickley <danbri@w3.org>, Tim Bray <tbray@textuality.com>, "Simon St.Laurent" <simonstl@simonstl.com>
Subject:   XML Catalog Proposal

I have written up a brief proposal for an XML Catalog specification based on our discussions. Note, the proposal is in the XML Catalog format and is located at:

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

The proposal demonstrates how the three types of XHTML1 and XHTML modularization DTDs as well as XML and RDF Schemata may be handled in an XML Catalog under a single namespace.

An XML Catalog DTD extended from XHTML1 is available at:

http://www.openhealth.org/XMLCatalog/xcat-xhtml1-strict.dtd http://www.openhealth.org/XMLCatalog/xcat-xhtml1-transitional.dtd

etc.

(of course the catalog would have told you that :-)

XML Catalog also includes the functionality of SGML Open Catalog Format through the inclusion of a "public" attribute (which is optional).

Happy New Millenium!

Jonathan

Date:      Mon, 01 Jan 2001 13:36:50 -0500
From:      Jonathan Borden <jborden@mediaone.net>
To:        xml-dev@lists.xml.org
Subject:   XML Namespace Catalog proposal 2nd edition

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

Prepared by Robin Cover for The XML Cover Pages archive. See also references in "Namespaces in XML."

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	XML Namespace Catalog Date: Sun, 31 Dec 2000 13:21:58 -0500 From: Jonathan Borden <jborden@mediaone.net> To: XML-Dev Mailing list <xml-dev@xml.org> Cc: Dan Brickley <danbri@w3.org>, Tim Bray <tbray@textuality.com>, "Simon St.Laurent" <simonstl@simonstl.com> Subject: XML Catalog Proposal I have written up a brief proposal for an XML Catalog specification based on our discussions. Note, the proposal is in the XML Catalog format and is located at: http://www.openhealth.org/XMLCatalog/ The proposal demonstrates how the three types of XHTML1 and XHTML modularization DTDs as well as XML and RDF Schemata may be handled in an XML Catalog under a single namespace. An XML Catalog DTD extended from XHTML1 is available at: http://www.openhealth.org/XMLCatalog/xcat-xhtml1-strict.dtd http://www.openhealth.org/XMLCatalog/xcat-xhtml1-transitional.dtd etc. (of course the catalog would have told you that :-) XML Catalog also includes the functionality of SGML Open Catalog Format through the inclusion of a "public" attribute (which is optional). Happy New Millenium! Jonathan Date: Mon, 01 Jan 2001 13:36:50 -0500 From: Jonathan Borden <jborden@mediaone.net> To: xml-dev@lists.xml.org Subject: XML Namespace Catalog proposal 2nd edition 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 Prepared by Robin Cover for The XML Cover Pages archive. See also references in "Namespaces in XML."