Bug #33


problems with replicating of DTDs, because of PUBLIC IDs

Added by Matt Jones almost 24 years ago. Updated over 21 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Clients submitting documents with new, unknown doctypes can provide a reference
or an internal subset for a DTD, which we currently use for validation, but do
not store. We need to store it so that it is not lost. The best way to do this
would be to store it in a long field in anothe rdatabase table, and provide a
method in MetaCatServlet for retreiving the DTD text.

Actions #1

Updated by Jivka Bojilova almost 24 years ago

Assigned to Jivka

Actions #2

Updated by Matt Jones over 23 years ago

This needs to be done, but it needs to be done in a coordinated manner among the
replicating servers. Today we (berkley, bojilova, jones, higgins, blankman)
decided that the catalog needed to be coordinated centrally, and that we need to
treat ISO registered formal public identifiers (FPI) differently from
non-registered FPIs. In particular, if a document is submitted with an ISO
registered FPI, and that FPI isn't in the catalog yet, then we must retrieve the
DTD from ISO (which may be a manual process) and store it (NOT the user provided
version). If it is a non-registered FPI, then the first person to use the FPI
defines the type by submitting the DTD with the document to Metacat, or by
providing a valid URL accessible to Metacat (from which we retrieve and cache
the DTD). If no DTD can be found for a document FPI, then we reject that
document (don't allow the insert or update to occur) with an appropriate error
message that tells the client it needs to provide the DTD.

We still need to decide if the catalog is purely a central resource shared by
all Metacat servers. We were leaning towards the decision that there would be a
primary and secondary Metacat server for the KNB, and that the catalog
information would be gathered from the primary Metacat server on a periodic
basis, and so all Metacat servers would be synchronized with respect to their
FPI/DTD caches.

Bojilova will need to coordinate with Berkley on the implementation of this
feature to deal with these replication issues.

Actions #3

Updated by Jivka Bojilova about 23 years ago

DTDs are stored on the server when registering new Doctypes

Actions #4

Updated by Jivka Bojilova about 23 years ago

There are problems for replicating of DTDs, because of PUBLIC IDs.
PUBLIC IDs probably should be unique (globally) b/w metacat servers

Actions #5

Updated by Jing Tao over 21 years ago

Public id is golable now. And replication between three metacat works well

Actions #6

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 33


Also available in: Atom PDF