If a system identifier is also provided as part of the input to this catalog lookup, only public entries that occur where the prefer setting is public are considered for matching. If a public identifier is provided, and one or more delegatePublic entries match, delegation is performed. If a system identifier is also provided as part of the input to this catalog lookup, only delegatePublic entries that occur where the prefer setting is public are considered for matching.
If delegation is to be performed, a new catalog entry file list is generated from the set of all matching delegatePublic entries. The value of the catalog attribute of each matching delegatePublic entry is inserted into the new catalog entry file list such that the delegate entry with the longest matching publicIdStartString is first on the list, the entry with the second longest match is second, etc.
Catalog resolution restarts using exclusively the catalog entry files in this new list and the given public identifier; any originally given system identifier is ignored during the remainder of the resolution of this external identifier: return to step 1. If the current catalog entry file contains one or more nextCatalog entries, the catalog entry files referenced by each nextCatalog entry's "catalog" attribute are inserted, in the order that they appear in this catalog entry file, onto the current catalog entry file list, immediately after the current catalog entry file.
If there are one or more catalog entry files remaining on the current catalog entry file list, load the next catalog entry file and continue resolution efforts: return to step 2. Indicate to the calling application that no match was found. Resolution continues by following the semantics of external identifier resolution Section 7.
Otherwise, resolution of the URI reference proceeds according to the steps below. Resolution of a generic URI reference follows the steps listed below, proceeding to each subsequent step if and only if no other action is indicated.
Resolution begins in the first catalog entry file in the current catalog list. If at least one matching uri entry exists, the absolutized value of the uri attribute of the first matching uri entry is returned. If at least one matching rewriteURI entry exists, rewriting is performed.
Rewriting removes the matching prefix and replaces it with the rewrite prefix identified by the matching rewriteURI entry. If one or more delegateURI entries match, delegation is performed. If delegation is to be performed, a new catalog entry file list is generated from the set of all matching delegateURI entries.
The absolutized value of the catalog attribute of each matching delegateURI entry is inserted into the new catalog entry file list such that the delegate entry with the longest matching uriStartString is first on the list, the entry with the second longest match is second, etc. Catalog resolution restarts using exclusively the catalog entry files in this new list and the given URI reference: return to step 1.
The catalog processor is sometimes required to load a catalog entry file. This may occur at the beginning of processing, when dealing with the initial list of catalog entry files, or during subsequent processing of a nextCatalog entry or one of the delegate entries. If the processor attempts to load a resource and fails because the resource does not exist or is not reachable, for example , it must recover by ignoring the catalog entry file that failed and proceeding.
Similarly, if the resource retrieved is not an understandable catalog because it is not in a format that the processor recognizes, or it purports to be XML but is not well-formed, or for any other reason , the processor must recover by responding as if the resource could not be loaded.
In order for a resource to be considered an XML Catalog, the following conditions must hold:. The resource retrieved must be well-formed [XML 1. The namespace name of the root element must be urn:oasis:names:tc:entity:xmlns:xml:catalog. It is not an error for catalog processors to accept other forms of catalog documents, but their identification and specification is outside the scope of this Standard.
This is an [XML 1. The syntax for a catalog entry file is partially [ 1 ] defined by this Document Type Definition:. For implementors wishing to provide full TR support, this appendix defines the elements that should be used for the remaining TR catalog entry types.
These are implemented as extension elements in the namespace: " urn:oasis:names:tc:entity:xmlns:trcatalog ". For a complete description of the semantics of these elements see [TR ].
The linktype element associates an external subset with a linktype declaration name. Tim Bray, Jean Paoli, and C. Sperberg-McQueen, Eve Maler, editors. World Wide Web Consortium, Namespaces in XML.
Walsh, J. Cowan, P. Grosso, Jonathan Marsh, editor. XML Base. Paul V. Biron and Ashok Malhotra, editors. James Clark, editor. World Wide Web Consortium. Paul Grosso, editor. Berners-Lee, R. Fielding, L. Hinden, B. Carpenter, L. Henry S. Thompson, David Beech, Murray Maloney, et al. Norman Walsh, editor. However, catalog files which make use of extension elements or attributes may be valid according to this Standard but invalid according to this DTD, due to the limits of DTD validation with respect to namespaces.
XML Catalogs. This version: Committee Specification: 06 Aug Walsh Sun. Abstract The requirement that all external identifiers in XML documents must provide a system identifier has unquestionably been of tremendous short-term benefit to the XML community. However, the interoperability of XML documents has been impeded in several ways by the lack of entity management facilities: External identifiers may require resources that are not always available.
Table of Contents 1. Introduction 2. Terminology 3. An Entity Catalog 4. Using Catalogs 4. External Identifier Entries 4. The prefer attribute 4. URI Entries 4. Rewrite Entries 4. Catalog Entry Files 5. Document Control of Catalog Entry Files 5. Catalog Circularities 6. XML Catalog Entries 6.
Common Attributes 6. Public Identifier Normalization 6. URN "Unwrapping" 6. Catalog Elements 6. The catalog Entry 6. The group Entry 6. The public Entry 6. The system Element 6. The rewriteSystem Element 6. The delegatePublic Element 6. The delegateSystem Element 6. The uri Element 6. The rewriteURI Element 6. The delegateURI Element 6. The nextCatalog Element 7. Catalog Resolution Semantics 7.
External Identifier Resolution 7. Input to the Resolver 7. Resolution of External Identifiers 7. URI Resolution 7. Resolution of URI references 8.
Resource Failures Appendixes A. The doctype Element E. The document Element E. The dtddecl Element E. The entity Element E. The linktype Element E. The notation Element E. The sgmldecl Element F. An Entity Catalog. Using Catalogs. External Identifier Entries. The prefer attribute. URI Entries. Rewrite Entries. These two kinds of catalog entries are used only to resolve DTD identifiers and system entity identifiers external files , not stylesheet references.
If you do not, the catalog processor will try to load the catalog. You cannot use the catalog to resolve its own DTD location. The catalog element contains the catalog content, and it includes a catalog namespace identifier. The group element is a wrapper element that sets attributes that apply to all the catalog entries contained in the group. The xml:base attribute is the location that all URIs are resolved relative to. The public element maps the given publicId string to the given uri location with the xml:base value prepended.
The system element maps the given systemId string to the same location. Why have multiple entries? The catalog resolver loads the catalog, and as it reads the files to be processed, it looks for items to resolve. It finds a match on the public identifier in the catalog, and since that entry's group wrapper element prefers using the public identifier, it uses that entry.
It uses the uri attribute value for that entry, and then prepends the xml:base value from its group wrapper. If it turns out that such a file is not at that location, then the catalog resolver looks for other catalog entries to resolve the item.
It then tries the first system entry, which in this case matches the www. If no catalog entry works, then the resolver gives up.
The XML catalog file that ships with version 4. If your resolver reports it as missing, then add an entry like the following to your catalog file:. When you are specifying an xml:base or uri attribute for use on a Microsoft Windows system, you must include the drive letter in the full URI syntax if you want it to work across processors. A Windows URI has this form:. It implements the org. EntityResolver SAX entity resolver and the org. These methods may be overridden if other behaviour is required.
If some other type of resolver is registered on the parser it will replace any XNI entity resolver previously registered. In addition to being used as an entity resolver, it is intended that the XMLCatalogResolver may be used standalone to perform catalog resolution outside of a parsing context. It may also be shared between several parsers and the application.
See the API documentation for details. If an instance of XMLCatalogResolver has been registered on the parser as an entity resolver it will first try to lookup the schema in the catalog by its target namespace if it has one using the catalog's uri entries.
If the schema has no target namespace, or the namespace is unavailable or no mapping for the namespace could be found the resolver will then try to locate the schema using any location hints provided. These location hints are interpreted to be system identifiers.
0コメント