[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New draft attached
I've attached my proposed edits. ...archives/entity-resolution-comment/200504/msg00005.html I haven't looked yet, but I don't think it relates directly to the spec. ...archives/entity-resolution-comment/200505/msg00000.html Fixed in the XML Schema. ...archives/entity-resolution-comment/200505/msg00001.html Fixed by changes to section 4.1.1. ...archives/entity-resolution-comment/200506/msg00000.html "Fixed" by responding to the commenter explaining why we did it that way. No changes to the spec. Be seeing you, normTitle: XML Catalogs
Working Draft 1.1, 21 June 2005
Copyright © 2000, 2001, 2002, 2003, 2005 OASIS Open, Inc. All Rights Reserved. Table of Contents
Appendixes
In order to make optimal use of the information about an XML external resource, there needs to be some interoperable way to map the information in an XML external identifier into a URI reference for the desired resource. This Working Draft defines an entity catalog that handles two simple cases:
Though it does not handle all issues that a combination of a complete entity manager and storage manager addresses, it simplifies both the use of multiple products in a great majority of cases and the task of processing documents on different systems. This entity catalog is designed to be compatible with [TR 9401] catalogs as mandated by the Technical Committee [Requirements]. This Working Draft provides several schema language descriptions of XML Catalogs in non-normative appendices. The semantics of XML Catalogs are defined normatively by the prose of this specfiication, not by any one of those schemas. The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this Working Draft are to be interpreted as described in [RFC 2119]. Note that for reasons of style, these words are not capitalized in this document. The terms URI and URI reference are to be interpreted as described in [RFC 2396]. The term external identifier is to be interpreted as defined in Production 75 of [XML]. External identifiers have two parts, an optional public identifier and a system identifier. The terms public identifier and system identifier in this Working Draft always refer to the respective part of an external identifier. NoteAll system identifiers are URI references, but not all URI references are system identifiers. A system identifer is always logically part of an external identifier, even when the public identifer is not provided. The logical input to a catalog processor is an external identifier (some combination of public and system identifiers) or a URI reference. The logical output of the catalog processor is a URI reference. (This Working Draft does not attempt to define an API for catalog processors so the logical interfaces and the practical interfaces may differ.) A catalog is a logical structure that contains "mapping" information. A catalog may be physically contained in one or more catalog entry files. A catalog entry file is a document that contains a set of catalog entries. This Working Draft defines an application-independent entity catalog that maps external identifiers and URI references to (other) URI references. It also defines a format for catalog entry files in terms of [XML] and [XML Namespaces]. The principal task of a catalog processor is to find entries in the catalog that match the input provided and return the associated URI reference as the output. The first such match is always used, and there is no requirement for the catalog processor to search for additional matches. This catalog is used by an application's entity manager. This Working Draft does not dictate when an entity manager should access this catalog; for example, an application may attempt other mapping algorithms before or after accessing this catalog. The catalog is effectively an ordered list of (one or more) catalog entry files. It is up to the application to determine the ordered list of catalog entry files to be used as the logical catalog. (This Working Draft uses the term "catalog entry file" to refer to one component of a logical catalog even though a catalog entry file can be any kind of storage object or entity including—but not limited to—a table in a database, some object identified by a URI reference, or some dynamically generated set of catalog entries.) Each entry in the catalog associates a URI reference with information about an external reference that appears in an XML document. For example, the following are possible catalog entries that associate a URI reference with a public identifier: <public publicId="ISO 8879:1986//ENTITIES Added Latin 1//EN" uri="iso-lat1.gml"/> <public publicId="-//USA/AAP//DTD BK-1//EN" uri="aapbook.dtd"/> <public publicId="-//Example, Inc.//DTD Report//EN" uri="http://www.example.com/dtds/report.dtd"/> This Working Draft defines the following catalog entry types: The namespace name defined by this Working Draft is " This Working Draft reserves all elements and attributes from its namespace for current and future use. In addition, unqualified attributes on elements in its namespace, other than the attributes explicitly described in this Working Draft, are reserved for future use. To provide for possible future extension and other applications of this catalog, its format allows for "other information" indicated by elements and attributes from namespaces other than the one defined by this Working Draft. A catalog can be used in two different, independent ways: (1) it can be used to locate the replacement text for an external entity, or (2) it can be used to locate an alternate URI reference for a resource. Although these functions are similar in nature, they are distinct and exercise two different sets of entries in the catalog. In either case, the following entries in the catalog are interpreted as follows:
The Catalog entry files identified by In the discussion that follows, note that catalog resolution semantics are not recursive. Once a matching catalog entry has been found, the value that results from that entry is returned without further examination of the catalog. External Identifiers, as defined in [Production 75] of [XML], identify the external subset, entities, and notations of an XML document. They are not used to identify other resources such as namespace names, stylesheets, and schema languages other than DTDs; URI entries are used for that purpose. For the purposes of resolving external identifiers, a catalog-based resolver considers the following entries:
Although system identifiers are assumed to be "URI reference[s]…meant to be dereferenced to obtain input for the XML processor to construct the entity's replacement text", in some circumstances (such as when the document was generated on another system, when the document was generated in another location on the same system, or when some files referenced by system identifiers have moved since the document was generated), the specified system identifiers are not always the best identifiers for the replacement text. For this or other reasons, it may be desirable to prefer the public identifier over the system identifier in determining the entity's replacement text. Therefore, this Working Draft defines two modes for searching the catalog: "prefer system identifier" mode and "prefer public identifier" mode.
The Each occurrence of a Note that setting There are nine possible combinations for each of the possible settings of When
When
An application must provide some way (e.g., a runtime argument, environment variable, preference switch) that allows the user to specify which of these modes to use in the absence of any occurrence of the When doing a catalog lookup, an entity manager generally uses whatever is available from among the entity declaration's system identifier and public identifier to find catalog entries that match the given information. A match in one catalog entry file will take precedence over any match in a later catalog entry file (and, in fact, the entity manager need not process subsequent catalog entry files once a match has occurred). URI references that are not part of an external identifier, such as namespace names, stylesheets, included files, graphics, and hypertext references, simply identify other resources. They are resolved using URI entries as described below. The input to a resolver that locates resources is simply the original URI reference. For the purposes of resolving URI references, a catalog-based resolver considers the following entries:
As when resolving URI references, a match in one catalog entry file will take precedence over any match in a later catalog entry file (and, in fact, the entity manager need not process subsequent catalog entry files once a match has occurred). Rewrite entries are provided as a convenience for performing redirection of a whole set of entities with a single catalog entry. Typical uses are website mirroring and dealing with fragment identifiers. Note that in the case of fragment identifiers, rewriting can only be applied to the URI that precedes the fragment identifier. The resolver never sees the fragment identifier part of the URI reference (the If the entire website at One way of doing this would be to create a <rewriteSystem systemIdStartString="http://www.example.com/" rewritePrefix="file:///share/mirrors/example/"/> Similarly, if you have a large number of references to a single document using many different fragment identifiers, it may be tedious to construct <rewriteURI uriStartString="http://www.example.com/old-location/" rewritePrefix="http://www.example.com/new-location/"/> Suffix entries are provided as a mechanism for matching based on the suffix of an identifier. The typical use case is to match a common entity based on its name rather than its full URI. For example, you can match a DTD such as xhtml1-strict.dtd or a schema such as docbook.rng regardless of the full system identifier or URI used in the document. For example, with this entry: <systemSuffix systemIdSuffix="html1-strict.dtd" uri="file:///share/mirrors/w3c/xhtml1/xhtml1-strict.dtd"/> any system identifier that ends in “xhtml1-strict.dtd” will be translated into the local copy of that DTD. This can be a great convenience if you receive documents from authors with different local configurations. Similarly, if there is variation in the absolute URI reference used to locate a particular resource, you can select it with just the suffix: <uriSuffix uriSuffix="/uniqueName.xsd" uri="file:///share/mirrors/schemas/example/uniqueName.xsd"/> Naturally, the ability to use system identifier or URI suffixes depends on the uniqueness of the suffix as a means of identifying the entity or resource. The catalog files in Example 1, “A DocBook XML Catalog File: docbook.xml.” and Example 2, “A Stylesheet XML Catalog File: stylesheet.xml.” are complete examples of XML Catalog files. Example 1. A DocBook XML Catalog File: docbook.xml. <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.1//EN" "http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <group xml:base="http://www.oasis-open.org/docbook/xml/4.1.2/"> <public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN" uri="docbookx.dtd"/> <public publicId="-//OASIS//ENTITIES DocBook XML Notations V4.1.2//EN" uri="dbnotnx.mod"/> <public publicId="-//OASIS//ENTITIES DocBook XML Character Entities V4.1.2//EN" uri="dbcentx.mod"/> <public publicId="-//OASIS//ELEMENTS DocBook XML Information Pool V4.1.2//EN" uri="dbpoolx.mod"/> <public publicId="-//OASIS//ELEMENTS DocBook XML Document Hierarchy V4.1.2//EN" uri="dbhierx.mod"/> <public publicId="-//OASIS//ENTITIES DocBook XML Additional General Entities V4.1.2//EN" uri="dbgenent.mod"/> <public publicId="-//OASIS//DTD DocBook XML CALS Table Model V4.1.2//EN" uri="calstblx.dtd"/> </group> <public publicId="-//OASIS//DTD DocBook MathML Module V1.0//EN" uri="http://www.oasis-open.org/docbook/xml/mathml/1.0/dbmathml.dtd"/> <nextCatalog catalog="stylesheet.xml"/> </catalog> Example 2. A Stylesheet XML Catalog File: stylesheet.xml. <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.1//EN" "http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <!-- Circumvent relative URI in spec.xsl that doesn't work online --> <uri name="http://www.oasis-open.org/committes/tr.xsl" uri="http://www.oasis-open.org/committes/entity/stylesheets/base/tr.xsl"/> </catalog> Together, these two catalog files provide sufficient resolution information to parse and format the XML source for this Working Draft. Applications conforming to this Working Draft must provide some (implementation dependent) mechanism that allows the user to establish the initial list of catalog entry files. This may be a preferences dialog, an environment variable, an application properties file, or any other appropriate mechanism. All conforming processors must accept and process catalog entry files written in the format described by this specification. They may also accept and process other formats, but they are not required to do so. If an application encounters a catalog entry file in a format that it does not understand, it must treat it as a resource failure. If a document contains external identifiers or URI references, it may be useful for the document to identify a catalog that is likely to aid in the resolution of those references. For example, XML documents stored on the www.example.com server may wish to indicate that http://www.example.com/catalog is a useful public catalog to use when parsing them. This Working Draft defines the processing instruction " If a document contains one or more Catalog entry files referenced by the processing instruction are added to the end of any system- or user-defined catalog entry file list. For example, in <?xml version="1.0"?> <?oasis-xml-catalog catalog="http://example.com/catalog.xml"?> <!DOCTYPE doc PUBLIC "-//Example//DTD Document V1.0//EN" "http://www.example.com/schema/doc.dtd"> ... The URI "http://example.com/catalog.xml" is added to the end of the of the list of catalog entry files used for resolution within this document. The following constraints apply:
Catalog-aware applications should support the One common idiom for controlling parser features is the use of a feature URI. This Working Draft defines the following feature URI for this purpose: http://www.oasis-open.org/committees/entity/features/catalog-pi If this feature is disabled, XML Catalog files are XML documents and as such may contain external identifiers and URI references. Conformant processors are not required to be able to perform resolution of those identifiers through the XML Catalog. Implementations are encouraged to provide some sort of bootstrapping functionality to resolve external identifiers and URIs that the implementation needs to load catalog entry files. For example, presented with the following catalog entry file: <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.1//EN" "http://www.oasis-open.org/committees/entity/release/1.1/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN" uri="docbookx.dtd"/> </catalog> an implementation should recognize the standard external identifier used on the catalog and provide the parser with access to that DTD in some implementation defined way if it's necessary. Users can avoid any problems that might arise by limiting the external identifiers and URIs used to those that do not need resolution. Note that this only applies to external identifiers and URIs that must be resolved in order to load the catalog entry file. For example, if a local copy of the XML Catalog DTD is available at /etc/xml/catalog.dtd, the problems of resolution associated with loading this file can be avoided by pointing directly to that local copy in the catalog entry file: <!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.1//EN" "/etc/xml/catalog.dtd"> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public"> <public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN" uri="docbookx.dtd"/> </catalog> As noted, catalog resolution semantics are not recursive. Once a matching catalog entry has been found, the value that results from that entry is returned without further examination of the catalog. In other words, if the catalog contains the following entries and only these entries: <uri name="http://example.com/path/resource" uri="http://example.com/alternate/resource"/> <uri name="http://example.com/alternate/resource" uri="http://example.com/final/resource"/> An attempt to resolve This avoids an obvious opportunity for circular reference inside the resolver. However, applications are free to make multiple calls to the resolver if they wish, in which case it is the responsibility of the application to handle any circularities that arise. Even so, catalog circularities may arise. Implementations should detect circularity, but it may be impractical or impossible in some circumstances. If a circularity is detected, it must be treated as an error. Applications may recover from this error by indicating to the calling application that no match was found. Given the dynamic nature of resources on the internet, it may not always be possible for implementations to detect circular references. Failure to detect circularity of references is not a failure to conform to this specification. Each catalog entry file consists of some number of catalog entries. Catalog entries are identified by the namespace name defined by this Working Draft. Elements and attributes from other namespaces are allowed, but their semantics are not defined by this specification. Implementations that encounter an element from a namespace they do not recognize must ignore it. If an element is ignored, all of its descendants must also be ignored, regardless of their namespace. There are two attributes common to most elements: All of the attributes defined by this Working Draft are in the per-element-type partition. Use of qualified attributes, for example, In order to accurately and interoperably compare public identifiers, catalog processors must perform normalization on public identifiers in both the catalog and the input passed to them. All strings of white space in public identifiers must be normalized to single space characters (#x20), and leading and trailing white space must be removed. In order to accurately and interoperably compare system identifiers and URI references, catalog processors must perform normalization. The normalization described in this section must be performed on system identifiers and URI references passed as input to the resolver and on strings in the catalog that are compared to them. URI references require encoding and escaping of certain characters. The disallowed characters include all non-ASCII characters, plus the excluded characters listed in Section 2.4 of [RFC 2396], except for the number sign (#) and percent sign (%) characters and the square bracket characters re-allowed in [RFC 2732]. These characters are summarized in Table 1, “Excluded US-ASCII Characters”. Table 1. Excluded US-ASCII Characters
Catalog processors must escape disallowed characters as follows:
Note that this normalization process is idempotent: repeated normalization does not change a normalized URI reference. This Working Draft requires processors to implement special treatment of URNs in the URNs of this form must, in some contexts, be "unwrapped" by the Catalog processor. This unwrapping translates the URN form of the public identifier back into the standard ISO 8879 form for the purposes of subsequent catalog processing. Unwrapping a
For example, the following URN in the urn:publicid:-:OASIS:DTD+DocBook+XML+V4.1.2:EN Represents the public identifier: -//OASIS//DTD DocBook XML V4.1.2//EN URNs in the URNs in the The root element of a catalog entry file is Each XML Catalog entry file consists of a single
The
NoteThe ability to scope the The
A If the value of the The
A If the value of the The
A If the value of the Rewriting removes the matching prefix from the supplied system identifier and replaces it with the value of the If more than one Given the following catalog fragment: <rewriteSystem systemIdStartString="http://www.oasis-open.org/" rewritePrefix="file:///share/doctypes/oasis/"/> <rewriteSystem systemIdStartString="http://www.oasis-open.org/docbook/" rewritePrefix="file:///sourceforge/docbook/docbook/"/> <rewriteSystem systemIdStartString="http://www.oasis-open.org/committees/" rewritePrefix="file:///projects/oasis/"/> The first two entries match the system identifier "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd", but the third does not. The rewritten system identifier in this case is: "file:///sourceforge/docbook/docbook/xml/4.1.2/docbookx.dtd". The
A If the value of the If more than one Given the following catalog fragment: <systemSuffix systemIdSuffix="docbookx.dtd" uri="file:///share/doctypes/xml/4.4/docbookx.dtd"/> <systemSuffix systemIdSuffix="4.3/docbookx.dtd" uri="file:///share/doctypes/xml/4.3/docbookx.dtd"/> The first entry matches the system identifier "file:/C|/local/docbookx.dtd" but the second matches "file:/C|/local/backup/4.3/docbookx.dtd" because “ The
A Given the following catalog fragment: <delegatePublic publicIdStartString="-//OASIS//" catalog="http://www.oasis-open.org/catalog"/> <delegatePublic publicIdStartString="-//OASIS//DTD DocBook " catalog="http://www.oasis-open.org/docbook/catalog"/> <delegatePublic publicIdStartString="-//OASIS//DTD XML Catalog //" catalog="http://www.oasis-open.org/committees/entity/catalog"/> The first two entries match the public identifier "-//OASIS//DTD DocBook V4.1.2//EN", but the third does not. If the value of the The
A Given the following catalog fragment: <delegateSystem systemIdStartString="http://www.oasis-open.org/" catalog="http://www.oasis-open.org/catalog"/> <delegateSystem systemIdStartString="http://www.oasis-open.org/docbook/" catalog="http://www.oasis-open.org/docbook/catalog"/> <delegatePublic publicIdStartString="http://www.oasis-open.org/committees/" catalog="http://www.oasis-open.org/committees/catalog"/> The first two entries match the system identifier "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd", but the third does not. If the value of the The
A Given the following catalog fragment: <uri name="http://www.oasis-open.org/committees/docbook/#membership" uri="file:///projects/oasis/docbook/website/#membership"/> <uri name="http://www.oasis-open.org/committees/docbook/" uri="file:///projects/oasis/docbook/website/"/> The second entry matches the URI reference "http://www.oasis-open.org/committees/docbook/", but the first does not. If the value of the The
A If the value of the Rewriting removes the matching prefix from the supplied URI reference and replaces it with the value of the value of the If more than one The
A If the value of the If more than one The
A If the value of the The
If the value of the Catalogs loaded due to a This section describes how catalog resolution is performed. Resolution begins with a list of catalog entry files and either an external identifier or a URI reference. This section describes how catalog entries are used to resolve external identifiers. An external identifier will have at least one and perhaps both of the following:
Resolvers should respect the system identifiers provided by authors. If the system part of the external identifier is relative, resolution should use that relative URI as the system identifier. If resolution with the relative form fails, it's reasonable for resolvers to try again using the absolute form. If the public identifier is a URN in the If the system identifier is a URN in the
Resolution follows the steps listed below, proceeding to each subsequent step if and only if no other action is indicated.
This section describes how catalog entries are used to resolve URI references. URI reference resolution always begins with a single URI reference. Resolvers should respect the URI references provided by authors. If the URI is relative, resolution should use that relative URI. If resolution with the relative form fails, it's reasonable for resolvers to try again using the absolute form. If the URI reference is a URN in the 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.
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 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:
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 Working Draft. XML Catalogs Working Draft 1.1 differs from the previous XML Catalogs Committee Specification 1.0 in only one significant way: it introduces By design, XML Catalogs defined by this Working Draft use the same namespace name as XML Catalogs Committee Specification 1.0. Although additional elements have been defined, the semantics of all existing elements remain unchanged. A. A W3C XML Schema for the XML Catalog (Non-Normative)This [W3C XML Schema] grammar defines the syntax for OASIS XML Catalog Working Draft entry files. This grammar has the following identifier:
<?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:er="urn:oasis:names:tc:entity:xmlns:xml:catalog" targetNamespace="urn:oasis:names:tc:entity:xmlns:xml:catalog" elementFormDefault="qualified"> <!-- $Id: catalog.xsd,v 1.14 2005/03/31 18:17:02 ndw Exp $ --> <xs:import namespace="http://www.w3.org/XML/1998/namespace"/> <xs:simpleType name="pubIdChars"> <!-- A string of the characters defined as pubIdChar in production 13 of the Second Edition of the XML 1.0 Recommendation. Does not include the whitespace characters because they're normalized by XML parsing. --> <xs:restriction base="xs:string"> <xs:pattern value="[a-zA-Z0-9\-'\(\)+,./:=?;!*#@$_%]*"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="publicIdentifier"> <xs:restriction base="er:pubIdChars"/> </xs:simpleType> <xs:simpleType name="partialPublicIdentifier"> <xs:restriction base="er:pubIdChars"/> </xs:simpleType> <xs:simpleType name="systemOrPublic"> <xs:restriction base="xs:string"> <xs:enumeration value="system"/> <xs:enumeration value="public"/> </xs:restriction> </xs:simpleType> <!-- The global attribute xml:base is not explicitly declared; --> <!-- it is allowed by the anyAttribute declarations. --> <xs:complexType name="catalog"> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element ref="er:public"/> <xs:element ref="er:system"/> <xs:element ref="er:uri"/> <xs:element ref="er:rewriteSystem"/> <xs:element ref="er:rewriteURI"/> <xs:element ref="er:uriSuffix"/> <xs:element ref="er:systemSuffix"/> <xs:element ref="er:delegatePublic"/> <xs:element ref="er:delegateSystem"/> <xs:element ref="er:delegateURI"/> <xs:element ref="er:nextCatalog"/> <xs:element ref="er:group"/> <xs:any namespace="##other" processContents="skip"/> </xs:choice> <xs:attribute ref="id"/> <xs:attribute name="prefer" type="er:systemOrPublic"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="public"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="publicId" type="er:publicIdentifier" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="system"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="systemId" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="uri"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="name" type="xs:anyURI" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="rewriteSystem"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="systemIdStartString" type="xs:string" use="required"/> <xs:attribute name="rewritePrefix" type="xs:string" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="rewriteURI"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="uriStartString" type="xs:string" use="required"/> <xs:attribute name="rewritePrefix" type="xs:string" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="systemSuffix"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="systemIdSuffix" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="uriSuffix"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="uriSuffix" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="delegatePublic"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="publicIdStartString" type="er:partialPublicIdentifier" use="required"/> <xs:attribute name="catalog" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="delegateSystem"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="systemIdStartString" type="xs:string" use="required"/> <xs:attribute name="catalog" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="delegateURI"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="uriStartString" type="xs:string" use="required"/> <xs:attribute name="catalog" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="nextCatalog"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="catalog" type="xs:anyURI" use="required"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType> <xs:complexType name="group"> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element ref="er:public"/> <xs:element ref="er:system"/> <xs:element ref="er:uri"/> <xs:element ref="er:rewriteSystem"/> <xs:element ref="er:rewriteURI"/> <xs:element ref="er:uriSuffix"/> <xs:element ref="er:systemSuffix"/> <xs:element ref="er:delegatePublic"/> <xs:element ref="er:delegateSystem"/> <xs:element ref="er:delegateURI"/> <xs:element ref="er:nextCatalog"/> <xs:any namespace="##other" processContents="skip"/> </xs:choice> <xs:attribute name="prefer" type="er:systemOrPublic"/> <xs:attribute ref="id"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="catalog" type="er:catalog"/> <xs:element name="public" type="er:public"/> <xs:element name="system" type="er:system"/> <xs:element name="uri" type="er:uri"/> <xs:element name="rewriteSystem" type="er:rewriteSystem"/> <xs:element name="rewriteURI" type="er:rewriteURI"/> <xs:element name="systemSuffix" type="er:systemSuffix"/> <xs:element name="uriSuffix" type="er:uriSuffix"/> <xs:element name="delegatePublic" type="er:delegatePublic"/> <xs:element name="delegateSystem" type="er:delegateSystem"/> <xs:element name="delegateURI" type="er:delegateURI"/> <xs:element name="nextCatalog" type="er:nextCatalog"/> <xs:element name="group" type="er:group"/> </xs:schema> B. A RELAX NG Grammar for the XML Catalog (Non-Normative)This [RELAX NG] grammar defines the syntax for OASIS XML Catalog Working Draft entry files. This grammar has the following identifier:
<?xml version="1.0"?> <grammar xmlns="http://relaxng.org/ns/structure/1.0" ns="urn:oasis:names:tc:entity:xmlns:xml:catalog" datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> <!-- $Id: catalog.rng,v 1.4 2005/02/25 18:54:25 ndw Exp $ --> <start> <choice> <ref name="Catalog"/> </choice> </start> <define name="pubIdChars"> <data type="string"> <param name="pattern">[a-zA-Z0-9\-'\(\)+,./:=?;!*#@$_% ]*</param> </data> </define> <define name="publicIdentifier"> <ref name="pubIdChars"/> </define> <define name="partialPublicIdentifier"> <ref name="pubIdChars"/> </define> <define name="systemOrPublic"> <choice> <value>system</value> <value>public</value> </choice> </define> <define name="uriReference"> <data type="anyURI"/> </define> <define name="OptionalAttributes"> <optional> <attribute name="id"> <data type="ID"/> </attribute> </optional> <zeroOrMore> <attribute> <anyName> <except> <nsName ns=""/> <nsName/> </except> </anyName> </attribute> </zeroOrMore> </define> <define name="PreferAttribute"> <attribute name="prefer"> <ref name="systemOrPublic"/> </attribute> </define> <define name="Catalog"> <element name="catalog"> <ref name="OptionalAttributes"/> <optional> <ref name="PreferAttribute"/> </optional> <oneOrMore> <choice> <ref name="Group"/> <ref name="Public"/> <ref name="System"/> <ref name="Uri"/> <ref name="RewriteSystem"/> <ref name="RewriteURI"/> <ref name="SystemSuffix"/> <ref name="UriSuffix"/> <ref name="DelegatePublic"/> <ref name="DelegateSystem"/> <ref name="DelegateURI"/> <ref name="NextCatalog"/> <ref name="AnyOtherElement"/> </choice> </oneOrMore> </element> </define> <define name="Group"> <element name="group"> <ref name="OptionalAttributes"/> <optional> <ref name="PreferAttribute"/> </optional> <oneOrMore> <choice> <ref name="Public"/> <ref name="System"/> <ref name="Uri"/> <ref name="RewriteSystem"/> <ref name="RewriteURI"/> <ref name="SystemSuffix"/> <ref name="UriSuffix"/> <ref name="DelegatePublic"/> <ref name="DelegateSystem"/> <ref name="DelegateURI"/> <ref name="NextCatalog"/> <ref name="AnyOtherElement"/> </choice> </oneOrMore> </element> </define> <define name="Public"> <element name="public"> <attribute name="publicId"> <ref name="publicIdentifier"/> </attribute> <attribute name="uri"> <ref name="uriReference"/> </attribute> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="System"> <element name="system"> <attribute name="systemId"/> <attribute name="uri"> <ref name="uriReference"/> </attribute> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="Uri"> <element name="uri"> <attribute name="name"/> <attribute name="uri"> <ref name="uriReference"/> </attribute> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="RewriteSystem"> <element name="rewriteSystem"> <attribute name="systemIdStartString"/> <attribute name="rewritePrefix"/> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="RewriteURI"> <element name="rewriteURI"> <attribute name="uriStartString"/> <attribute name="rewritePrefix"/> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="SystemSuffix"> <element name="systemSuffix"> <attribute name="systemIdSuffix"/> <attribute name="uri"> <ref name="uriReference"/> </attribute> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="UriSuffix"> <element name="uriSuffix"> <attribute name="uriSuffix"/> <attribute name="uri"> <ref name="uriReference"/> </attribute> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="DelegatePublic"> <element name="delegatePublic"> <attribute name="publicIdStartString"/> <attribute name="catalog"/> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="DelegateSystem"> <element name="delegateSystem"> <attribute name="systemIdStartString"/> <attribute name="catalog"/> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="DelegateURI"> <element name="delegateURI"> <attribute name="uriStartString"/> <attribute name="catalog"/> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="NextCatalog"> <element name="nextCatalog"> <attribute name="catalog"/> <ref name="OptionalAttributes"/> <empty/> </element> </define> <define name="AnyOtherElement"> <element> <anyName> <except> <nsName ns=""/> <nsName/> </except> </anyName> <zeroOrMore> <attribute> <anyName/> </attribute> </zeroOrMore> <choice> <text/> <ref name="AnyOtherElement"/> </choice> </element> </define> </grammar> C. A DTD for the XML Catalog (Non-Normative)This [XML] DTD grammar partially[1] defines the syntax for OASIS XML Catalog Working Draft entry files. This DTD has the following identifiers:
<!-- $Id: catalog.dtd,v 1.14 2005/04/13 20:47:06 ndw Exp $ --> <!ENTITY % pubIdChars "CDATA"> <!ENTITY % publicIdentifier "%pubIdChars;"> <!ENTITY % partialPublicIdentifier "%pubIdChars;"> <!ENTITY % uriReference "CDATA"> <!ENTITY % string "CDATA"> <!ENTITY % systemOrPublic "(system|public)"> <!ENTITY % p ""> <!ENTITY % s ""> <!ENTITY % nsdecl "xmlns%s;"> <!ENTITY % catalog "%p;catalog"> <!ENTITY % public "%p;public"> <!ENTITY % system "%p;system"> <!ENTITY % uri "%p;uri"> <!ENTITY % rewriteSystem "%p;rewriteSystem"> <!ENTITY % rewriteURI "%p;rewriteURI"> <!ENTITY % systemSuffix "%p;systemSuffix"> <!ENTITY % uriSuffix "%p;uriSuffix"> <!ENTITY % delegatePublic "%p;delegatePublic"> <!ENTITY % delegateSystem "%p;delegateSystem"> <!ENTITY % delegateURI "%p;delegateURI"> <!ENTITY % nextCatalog "%p;nextCatalog"> <!ENTITY % group "%p;group"> <!ENTITY % local.catalog.mix ""> <!ENTITY % local.catalog.attribs ""> <!ELEMENT %catalog; (%public;|%system;|%uri; |%rewriteSystem;|%rewriteURI; |%systemSuffix;|%uriSuffix; |%delegatePublic;|%delegateSystem;|%delegateURI; |%nextCatalog;|%group; %local.catalog.mix;)+> <!ATTLIST %catalog; %nsdecl; %uriReference; #FIXED 'urn:oasis:names:tc:entity:xmlns:xml:catalog' id ID #IMPLIED prefer %systemOrPublic; #IMPLIED xml:base %uriReference; #IMPLIED %local.catalog.attribs; > <!ENTITY % local.public.attribs ""> <!ELEMENT %public; EMPTY> <!ATTLIST %public; id ID #IMPLIED publicId %publicIdentifier; #REQUIRED uri %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.public.attribs; > <!ENTITY % local.system.attribs ""> <!ELEMENT %system; EMPTY> <!ATTLIST %system; id ID #IMPLIED systemId %string; #REQUIRED uri %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.system.attribs; > <!ENTITY % local.uri.attribs ""> <!ELEMENT %uri; EMPTY> <!ATTLIST %uri; id ID #IMPLIED name %string; #REQUIRED uri %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.uri.attribs; > <!ENTITY % local.rewriteSystem.attribs ""> <!ELEMENT %rewriteSystem; EMPTY> <!ATTLIST %rewriteSystem; id ID #IMPLIED systemIdStartString %string; #REQUIRED rewritePrefix %string; #REQUIRED %local.rewriteSystem.attribs; > <!ENTITY % local.rewriteURI.attribs ""> <!ELEMENT %rewriteURI; EMPTY> <!ATTLIST %rewriteURI; id ID #IMPLIED uriStartString %string; #REQUIRED rewritePrefix %string; #REQUIRED %local.rewriteURI.attribs; > <!ENTITY % local.systemSuffix.attribs ""> <!ELEMENT %systemSuffix; EMPTY> <!ATTLIST %systemSuffix; id ID #IMPLIED systemIdSuffix %string; #REQUIRED uri %string; #REQUIRED %local.systemSuffix.attribs; > <!ENTITY % local.uriSuffix.attribs ""> <!ELEMENT %uriSuffix; EMPTY> <!ATTLIST %uriSuffix; id ID #IMPLIED uriSuffix %string; #REQUIRED uri %string; #REQUIRED %local.uriSuffix.attribs; > <!ENTITY % local.delegatePublic.attribs ""> <!ELEMENT %delegatePublic; EMPTY> <!ATTLIST %delegatePublic; id ID #IMPLIED publicIdStartString %partialPublicIdentifier; #REQUIRED catalog %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.delegatePublic.attribs; > <!ENTITY % local.delegateSystem.attribs ""> <!ELEMENT %delegateSystem; EMPTY> <!ATTLIST %delegateSystem; id ID #IMPLIED systemIdStartString %string; #REQUIRED catalog %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.delegateSystem.attribs; > <!ENTITY % local.delegateURI.attribs ""> <!ELEMENT %delegateURI; EMPTY> <!ATTLIST %delegateURI; id ID #IMPLIED uriStartString %string; #REQUIRED catalog %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.delegateURI.attribs; > <!ENTITY % local.nextCatalog.attribs ""> <!ELEMENT %nextCatalog; EMPTY> <!ATTLIST %nextCatalog; id ID #IMPLIED catalog %uriReference; #REQUIRED xml:base %uriReference; #IMPLIED %local.nextCatalog.attribs; > <!ENTITY % local.group.mix ""> <!ENTITY % local.group.attribs ""> <!ELEMENT %group; (%public;|%system;|%uri; |%rewriteSystem;|%rewriteURI; |%systemSuffix;|%uriSuffix; |%delegatePublic;|%delegateSystem;|%delegateURI; |%nextCatalog; %local.group.mix;)+> <!ATTLIST %group; id ID #IMPLIED prefer %systemOrPublic; #IMPLIED xml:base %uriReference; #IMPLIED %local.group.attribs; > D. Support for TR9401 Catalog Semantics (Non-Normative)This Working Draft defines a subset of the catalog entry types described in [TR 9401] that are applicable to XML. For implementors wishing to provide full TR9401 support, this appendix defines the elements that should be used for the remaining TR9401 catalog entry types. The elements described in this appendix provide full TR9401 semantics in the XML Catalog format. These are implemented as extension elements in the namespace: " For a complete description of the semantics of these elements see [TR 9401]. The
The
The
The
The
E. OASIS Entity Resolution Committee (Non-Normative)The following individuals are members of the committee that developed this Working Draft:
The following additional individuals were members of the committee during the development of previous versions:
F. NoticesCopyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001, 2002, 2003, 2004, 2005. All Rights Reserved. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS has been notified of intellectual property rights claimed in regard to some or all of the contents of this specification. For more information consult the online list of claimed rights. G. Intellectual Property RightsFor information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Entity Resolution web page (http://www.oasis-open.org/committees/entity/) Normative[XML] Tim Bray, Jean Paoli, and C. M. Sperberg-McQueen, Eve Maler, editors. Extensible Markup Language (XML) 1.0 Second Edition. World Wide Web Consortium, 2000. [XML Namespaces] Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. World Wide Web Consortium, 1999. [RFC 2119] IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. 1997. [RFC 3151] IETF (Internet Engineering Task Force). RFC 3151: A URN Namespace for Public Identifiers. N. Walsh, J. Cowan, P. Grosso, 2001. [XML Base] Jonathan Marsh, editor. XML Base. World Wide Web Consortium, 2000. Non-Normative[XML Schema Datatypes] Paul V. Biron and Ashok Malhotra, editors. XML Schema Part 2: Datatypes. World Wide Web Consortium, 2000. [RELAX NG] James Clark and MURATA Makoto, editors. RELAX NG Specification. OASIS. 2001. [XML Stylesheets] James Clark, editor. Associating Style Sheets with XML Documents Version 1.0. World Wide Web Consortium. 1999. [TR 9401] Paul Grosso, editor. OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401). OASIS. 1997. [RFC 2279] IETF (Internet Engineering Task Force). RFC 2279: UTF-8, a transformation format of ISO 10646. F. Yergeau. 1998. [RFC 2396] IETF (Internet Engineering Task Force). RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. 1998. [RFC 2732] IETF (Internet Engineering Task Force). RFC 2732: Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. 1999. [W3C XML Schema] Henry S. Thompson, David Beech, Murray Maloney, et al. editors. XML Schema Part 1: Structures. World Wide Web Consortium, 2000. [Requirements] Norman Walsh, editor. OASIS Entity Resolution Technical Committee Requirements Document. OASIS. 2000. [1] Any catalog file which is valid according to this DTD is valid according to this Working Draft. However, catalog files which make use of extension elements or attributes may be valid according to this Working Draft but invalid according to this DTD, due to the limits of DTD validation with respect to namespaces. |
-- Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc. NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]