Java Doc for Catalog.java in  » 6.0-JDK-Modules » jaxb-xjc » com » sun » org » apache » xml » internal » resolver » Java Source Code / Java DocumentationJava Source Code and Java Documentation

This class implements the semantics of OASIS Open Catalog files (defined by OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401)).

The primary purpose of the Catalog is to associate resources in the document with local system identifiers. Some entities (document types, XML entities, and notations) have names and all of them can have either public or system identifiers or both. (In XML, only a notation can have a public identifier without a system identifier, but the methods implemented in this class obey the Catalog semantics from the SGML days when system identifiers were optional.)

The system identifiers returned by the resolution methods in this class are valid, i.e. usable by, and in fact constructed by, the java.net.URL class. Unfortunately, this class seems to behave in somewhat non-standard ways and the system identifiers returned may not be directly usable in a browser or filesystem context.

This class recognizes all of the Catalog entries defined in TR9401:1997:

• BASE changes the base URI for resolving relative system identifiers. The initial base URI is the URI of the location of the catalog (which is, in turn, relative to the location of the current working directory at startup, as returned by the user.dir system property).
• CATALOG processes other catalog files. An included catalog occurs logically at the end of the including catalog.
• DELEGATE_PUBLIC specifies alternate catalogs for some public identifiers. The delegated catalogs are not loaded until they are needed, but they are cached once loaded.
• DELEGATE_SYSTEM specifies alternate catalogs for some system identifiers. The delegated catalogs are not loaded until they are needed, but they are cached once loaded.
• DELEGATE_URI specifies alternate catalogs for some URIs. The delegated catalogs are not loaded until they are needed, but they are cached once loaded.
• REWRITE_SYSTEM specifies alternate prefix for a system identifier.
• REWRITE_URI specifies alternate prefix for a URI.
• SYSTEM_SUFFIX maps any system identifier that ends with a particular suffix to another system identifier.
• URI_SUFFIX maps any URI that ends with a particular suffix to another URI.
• DOCTYPE associates the names of root elements with URIs. (In other words, an XML processor might infer the doctype of an XML document that does not include a doctype declaration by looking for the DOCTYPE entry in the catalog which matches the name of the root element of the document.)
• DOCUMENT provides a default document.
• DTDDECL recognized and silently ignored. Not relevant for XML.
• ENTITY associates entity names with URIs.
• LINKTYPE recognized and silently ignored. Not relevant for XML.
• NOTATION associates notation names with URIs.
• OVERRIDE changes the override behavior. Initial behavior is set by the system property xml.catalog.override. The default initial behavior is 'YES', that is, entries in the catalog override system identifiers specified in the document.
• PUBLIC maps a public identifier to a system identifier.
• SGMLDECL recognized and silently ignored. Not relevant for XML.
• SYSTEM maps a system identifier to another system identifier.
• URI maps a URI to another URI.

Note that BASE entries are treated as described by RFC2396. In particular, this has the counter-intuitive property that after a BASE entry identifing "http://example.com/a/b/c" as the base URI, the relative URI "foo" is resolved to the absolute URI "http://example.com/a/b/foo". You must provide the trailing slash if you do not want the final component of the path to be discarded as a filename would in a URI for a resource: "http://example.com/a/b/c/".

Note that subordinate catalogs (all catalogs except the first, including CATALOG and DELEGATE* catalogs) are only loaded if and when they are required.

This class relies on classes which implement the CatalogReader interface to actually load catalog files. This allows the catalog semantics to be implemented for TR9401 text-based catalogs, XML catalogs, or any number of other storage formats.

Additional catalogs may also be loaded with the Catalog.parseCatalog method.

Change Log:

2.0

Rewrite to use CatalogReaders.

1.1

Allow quoted components in xml.catalog.files so that URLs containing colons can be used on Unix. The string passed to xml.catalog.files can now have the form:

 unquoted-path-with-no-sep-chars:"double-quoted path with or without sep chars":'single-quoted path with or without sep chars'
 

(Where ":" is the separater character in this example.)

If an unquoted path contains an embedded double or single quote character, no special processig is performed on that character. No path can contain separater characters, double, and single quotes simultaneously.

Fix bug in calculation of BASE entries: if a catalog contains multiple BASE entries, each is relative to the preceding base, not the default base URI of the catalog.

1.0.1

Fixed a bug in the calculation of the list of subordinate catalogs. This bug caused an infinite loop where parsing would alternately process two catalogs indefinitely.

Derived from public domain code originally published by Arbortext,
version:
   Inc.

The semantics of Catalog resolution are such that each catalog is effectively a list of Catalogs (in other words, a recursive list of Catalog instances).

Catalogs that are processed as the result of CATALOG or DELEGATE* entries are subordinate to the catalog that contained them, but they may in turn have subordinate catalogs.

Catalogs are only loaded when they are needed, so this vector initially contains a list of Catalog filenames (URLs).

This two-level system is actually necessary to correctly implement the semantics of the CATALOG entry.

This two-level system has two purposes; first, it allows us to sort the DELEGATE* entries by the length of the partial public identifier so that a linear search encounters them in the correct order and second, it puts them all at the end of the Catalog.

When processing reaches the end of each catalog file, any elements on this vector are added to the end of the catalogEntries vector.

This vector contains all of the readers in the order that they were added.

This hash maps MIME types to elements in the readerArr vector.

This method allows you to add a new CatalogReader to the catalog.

This method constructs a new instance of the running Catalog class (which might be a subtype of com.sun.org.apache.xml.internal.resolver.Catalog). All new catalogs are managed by the same CatalogManager.

N.B.

This method supports catalog files stored in jar files: e.g., jar:file:///path/to/filename.jar!/path/to/catalog.xml".

This method searches the Catalog and returns the system identifier specified for the given system or public identifiers. If no appropriate PUBLIC or SYSTEM entry is found in the Catalog, delegated Catalogs are interrogated.

There are four possible cases:

• If the system identifier provided matches a SYSTEM entry in the current catalog, the SYSTEM entry is returned.
• If the system identifier is not null, the PUBLIC entries that were encountered when OVERRIDE YES was in effect are interrogated and the first matching entry is returned.
• If the system identifier is null, then all of the PUBLIC entries are interrogated and the first matching entry is returned.

This method searches the Catalog and returns the system identifier specified for the given system or public identifiers.

This method searches the Catalog and returns the system identifier specified for the given entity type with the given name, public, and system identifiers.

If a SYSTEM entry exists in the Catalog for the system ID specified, return the mapped value.

On Windows-based operating systems, the comparison between the system identifier provided and the SYSTEM entries in the Catalog is case-insensitive.

If a URI entry exists in the Catalog for the URI specified, return the mapped value.

URI comparison is case sensitive.

This list is initially established by loadSystemCatalogs when it parses the system catalog list, but CATALOG entries may contribute to it during the course of parsing.

The semantics of Catalog resolution are such that each catalog is effectively a list of Catalogs (in other words, a recursive list of Catalog instances).

Catalogs that are processed as the result of CATALOG or DELEGATE* entries are subordinate to the catalog that contained them, but they may in turn have subordinate catalogs.

Catalogs are only loaded when they are needed, so this vector initially contains a list of Catalog filenames (URLs). If, during processing, one of these catalogs has to be loaded, the resulting Catalog object is placed in the vector, effectively caching it for the next query.

This two-level system is actually necessary to correctly implement the semantics of the CATALOG entry. If one catalog file includes another with a CATALOG entry, the included catalog logically occurs at the end of the including catalog, and after any preceding CATALOG entries. In other words, the CATALOG entry cannot insert anything into the middle of a catalog file.

When processing reaches the end of each catalog files, any elements on this vector are added to the front of the catalogFiles vector.

This two-level system has two purposes; first, it allows us to sort the DELEGATE* entries by the length of the partial public identifier so that a linear search encounters them in the correct order and second, it puts them all at the end of the Catalog.

When processing reaches the end of each catalog file, any elements on this vector are added to the end of the catalogEntries vector. This assures that matching PUBLIC keywords are encountered before DELEGATE* entries.

This vector contains all of the readers in the order that they were added. In the event that a catalog is read from a file, where the MIME type is unknown, each reader is attempted in turn until one succeeds.

This hash maps MIME types to elements in the readerArr vector. This allows the Catalog to quickly locate the reader for a particular MIME type.

The constructor interrogates the relevant system properties using the default (static) CatalogManager and initializes the catalog data structures.

The constructor interrogates the relevant system properties using the specified Catalog Manager and initializes the catalog data structures.

This method always constructs the Catalog.localDelegate vector so that it is ordered by length of partial public identifier.

This method processes each Catalog entry, changing mapped relative system identifiers into absolute ones (based on the current base URI), and maintaining other information about the current catalog.

This method allows you to add a new CatalogReader to the catalog. The reader will be associated with the specified mimeType. You can only have one reader per mimeType.

In the absence of a mimeType (e.g., when reading a catalog directly from a file on the local system), the readers are attempted in the order that you add them to the Catalog.

Note that subordinate catalogs (created by CATALOG or DELEGATE* entries) get a copy of the set of readers present in the primary catalog when they are created. Readers added subsequently will not be available. For this reason, it is best to add all of the readers before the first call to parse a catalog.

This method is used internally when constructing a new catalog. It copies the current reader associations over to the new catalog.

All catalog files loaded by this catalog will have the initial override setting specified by this default.

The method adds all of the catalogs specified in the xml.catalog.files property to the Catalog list.

This method constructs a new instance of the running Catalog class (which might be a subtype of com.sun.org.apache.xml.internal.resolver.Catalog). All new catalogs are managed by the same CatalogManager.

N.B. All Catalog subtypes should call newCatalog() to construct a new Catalog. Do not simply use "new Subclass()" since that will confuse future subclasses.

This method recursively parses all of the subordinate catalogs. If this method does not throw an exception, you can be confident that no subsequent call to any resolve*() method will either, with two possible exceptions:

1. Delegated catalogs are re-parsed each time they are needed (because a variable list of them may be needed in each case, depending on the length of the matching partial public identifier).

   But they are parsed by this method, so as long as they don't change or disappear while the program is running, they shouldn't generate errors later if they don't generate errors now.

2. If you add new catalogs with parseCatalog, they won't be loaded until they are needed or until you call parseAllCatalogs again.

On the other hand, if you don't call this method, you may successfully parse documents without having to load all possible catalogs.

Catalogs retrieved over the net may have an associated MIME type. The MIME type can be used to select an appropriate reader.

This method supports catalog files stored in jar files: e.g., jar:file:///path/to/filename.jar!/path/to/catalog.xml". That URI doesn't survive transmogrification through the URI processing that the parseCatalog(String) performs and passing it as an input stream doesn't set the base URI appropriately.

Written by Stefan Wachter (2002-09-26)

Catalogs may refer to other catalogs, this method parses all of the currently pending catalog files.

This method searches the Catalog and returns the system identifier specified for the given system or public identifiers. If no appropriate PUBLIC or SYSTEM entry is found in the Catalog, delegated Catalogs are interrogated.

There are four possible cases:

• If the system identifier provided matches a SYSTEM entry in the current catalog, the SYSTEM entry is returned.
• If the system identifier is not null, the PUBLIC entries that were encountered when OVERRIDE YES was in effect are interrogated and the first matching entry is returned.
• If the system identifier is null, then all of the PUBLIC entries are interrogated and the first matching entry is returned. This may not be the same as the preceding case, if some PUBLIC entries are encountered when OVERRIDE NO is in effect. In XML, the only place where a public identifier may occur without a system identifier is in a notation declaration.
• Finally, if the public identifier matches one of the partial public identifiers specified in a DELEGATE* entry in the Catalog, the delegated catalog is interrogated. The first time that the delegated catalog is required, it will be retrieved and parsed. It is subsequently cached.

If a SYSTEM entry exists in the catalog file for the system ID specified, return the mapped value.

If a URI entry exists in the catalog file for the URI specified, return the mapped value.

This method searches the Catalog and returns the system identifier specified for the given system or public identifiers. If no appropriate PUBLIC or SYSTEM entry is found in the Catalog, null is returned.

This method searches the Catalog and returns the system identifier specified for the given entity type with the given name, public, and system identifiers. In some contexts, these may be null.

If a SYSTEM entry exists in the Catalog for the system ID specified, return the mapped value.

On Windows-based operating systems, the comparison between the system identifier provided and the SYSTEM entries in the Catalog is case-insensitive.

If a URI entry exists in the Catalog for the URI specified, return the mapped value.

URI comparison is case sensitive.

This method exists to allow subclasses to deal with unknown entry types.