Project

General

Profile

Bug #33

problems with replicating of DTDs, because of PUBLIC IDs

Added by Matt Jones over 19 years ago. Updated almost 17 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
06/27/2000
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
33

Description

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.

History

#1 Updated by Jivka Bojilova over 19 years ago

Assigned to Jivka

#2 Updated by Matt Jones almost 19 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.

#3 Updated by Jivka Bojilova over 18 years ago

DONE
DTDs are stored on the server when registering new Doctypes

#4 Updated by Jivka Bojilova over 18 years ago

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

#5 Updated by Jing Tao almost 17 years ago

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

#6 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 33

Also available in: Atom PDF