Re: XML catalog draft
| I think that it would be better to specify that URNs be used (which I
| would support) than FPIs (which I do not support), as there is still
| no resolution mechanism that will scale up to millions of FPIs even
| proposed, let alone working, as far as I can see.
With all due respect for the URN effort, I'm not convinced that it's
very far along toward implementation, either. And I'm beginning to
suspect that we could, in fact, come up with a believable resolution
mechanism for millions of FPIs.
This is just a sketch, but consider:
Given DELEGATE, a catalog-based mechanism works for a reasonably large
number of FPIs on something the size of a corporate network. The
problem comes when something links to an FPI that's not in the space
defined by local catalogs.
Let's suppose that "-//FOOCORP::FOOAUTH//DOCUMENT sometitle
ver1.01//EN" fails to find resolution at the local level. Postulate
the existence of a server (probably mirrored, but let's stay above
that level of detail for the nonce) funded by every organization that
wishes to use this mechanism. Let's call this server xmlid.net. That
server does not have a listing for every FPI; all it has is one (and
only one) entry for every publisher that has joined the cooperative.
So on that server there is a single lookup table cached in RAM, one
line of which consists of FOOCORP::FOOAUTH on one side and
foodocs.foo.com on the other.
Add to the abilities assumed for the XML client under the XML catalog
proposal the following: it can query xmlid.net with the string
FOOCORP::FOOAUTH and get back foodocs.foo.com; it can then query
foodocs.foo.com for its corporate catalog; and it can add that
corporate catalog to its own for long enough to resolve the query (or
fail, but that's entirely FooCorp's responsibility).
This isn't enough to build a resolution mechanism, but it's enough to
think that building one might be possible. Is there anything
basically wrong with the idea?