Resource discovery directory [was: XML Catalog proposal]

[Paul Grosso <pgrosso@arbortext.com>]

I've scanned this thread, and this seemed like the best message
to which to reply given my thoughts, but I realize there are
many other messages that are relevant (perhaps esp Miles Sabin's
at [1], but I'm not sure I completely understood his points).

I think the idea under discussion that Tim Bray restarted (it's
been discussed many times before) is to define some kind of
standard format for a resource that might be at the end of
a namespace URI wherein that resource points to multiple other
resources.  I think many of us have thought this is a good idea,
and I'm glad to see that xml-dev appears to have some cycles now
to make progress on this issue.  

(Note that this is one of the ideas that were part of the XML 
Packaging effort that was first supposed to happen as part 
of the W3C XML activity and then was made public [2] hoping that 
xml-dev would do something about it, but it didn't catch on.  
Funny how some things that don't catch on for the first N times 
all of a sudden seem to catch on the N+1st time.  Well, I'm just 
glad it finally happened.)

As Dan Vint's message points out, calling this a catalog can
lead to confusion.  The OASIS Entity Management catalog [3],
John Cowan's XML-ization of it called XML Catalog [4], and 
the current OASIS Entity Resolution Technical Committee (ERTC)
work [5] on standardizing an XML ER catalog (xmlcat) are all 
talking about a mechanism to map external identifier information
(e.g., public ids, system ids, and namespace names) to URIs.

What the current discussion is about is defining the format
of a resource discovery "directory".  (See also Tim Bray's paper
of Sept 1999 [6].)  I would strongly suggest we avoid the word
"catalog" in the current discussion.

I'd also suggest we avoid mixing ER catalogs with resource 
discovery (RD) directories.  These things are at different
levels and should not be mixed.  Mapping external ids is
something that happens in the middle of an XML parsing
process by an entity resolver (a module called by the
XML parser itself), whereas using a RD directory to find
a stylesheet or a metadata or relevant external code is
something that happens "above" the level of the parser.

I do think there is a potentially useful synergy between
the ER catalog and the RD directory, and maybe this addresses
Miles' concern (but I'm not sure).  Assuming the OASIS xmlcat
includes a NAMESPACE entry type (as I expect it will), then
any namespace name found in a document could be "redirected"
to any URI you wish via the xmlcat.  This is independent of
any RD directory discussion whatsoever.  But then the resource
that is actually found at that URI could well be an RD
directory.  Since users can define local xmlcats, users can
optionally influence which RD directory they want to use.

paul

[1] http://lists.xml.org/archives/xml-dev/200101/msg00025.html
[2] http://lists.w3.org/Archives/Public/www-xml-packaging/2000Jul/att-0001/01-pkg-note.htm
[3] http://www.oasis-open.org/committees/entity/9401.html
[4] http://www.ccil.org/~cowan/XML/XCatalog.html
[5] http://www.oasis-open.org/committees/entity/
[6] http://www.textuality.com/xml/why-pkg.html

At 15:05 2000 12 31 -0500, Jonathan Borden wrote:
>Dan Vint wrote:
>> So can you summarize the differnces between the OASIS catalog format that
>> is already supported with a free Java Class and what you are proposing?

>1) An XML Catalog is intended to be retrieved by dereferencing an XML
>namespace URI and is intended to support mapping a single namespace URI to
>multiple resources (1:many). An OASIS catalog is intended to map an FPI to a
>resource (1:1). An XML Catalog extends the functionality of an OASIS catalog
>by supporting a "public" attribute on the link element.
>
>2) An XML Catalog is an extension of XHTML and is hence viewable in browsers
>and manipulatable by common XML software (e.g. SAX, XSLT)
>
>3) One can certainly include an OASIS Open Catalog Format document as a
>linked resource within an XML Catalog document. I will add this as an
>example to the specification.