Re: [dita] Catalog files as part of the submission?

[Christopher Wong <cwong@idiominc.com>]

Here are some reasons why I prefer the status quo of providing catalogs using public IDs, in no particular order:

1. FrameMaker 7.1 must use public IDs for entity lookups. Whether using a catalog or the structured application definition, you can only specify the public -- not system -- ID.
2. The DITA DTDs are using public IDs for external entities. Providing catalogs without support for these lookups is just ridiculous.
   
3. Some components of an authoring system do not allow network references: the DTD must be on the local (or look local) filesystem. FrameMaker comes to mind. An absolute network-based URL will not work.
   
4. Some components do not have catalog capability. Web browsers like IE come to mind. Forcing users to always load the DTDs off the Internet is not an option. An absolute network-based URL will not work.
5. Some tools cannot handle DITA's multi-module format and need a local custom (flattened) DTD file. Trados comes to mind. An absolute network-based URL will not work.
   
6. Some users cannot count on an Internet connection, whether for security, performance or connectivity reasons. An absolute, network-based URL will not work.
7. As I understand it, you want to use an absolute URI as a "magic lookup string" for catalogs, much as public IDs are used now. This simply means that for DTDs we are requiring 2 parallel, redundant sets of magic lookup strings, adding confusion and complexity.
8. Following the DITA toolkit's lead, we at Idiom have been implementing infrastructure based on the combination of public IDs and relative system IDs. We have adopted the toolkit's catalog as part of this infrastructure. We have assumed the presence of a relative system ID for local filesystem access. The change you suggest is disruptive.
9. My understanding is that version 1.0 of this spec is supposed to ratify current practice, with minimal disruption. Dropping public IDs from the catalogs is counter to this intent.
   

You will get your identifier purity eventually. When all tools move to XML schema, public IDs will naturally disappear. Forcing an absolute URI convention onto existing, unready DTD infrastructure, however, is unproductive.

Chris

W. Eliot Kimber wrote:

My preference would be that all external identifiers be specified as absolute URIs that are then mapped to local versions using supplied catalogs. This could replace the current use of public identifiers in all entity declarations (but doesn't have to--regardless of whether or not public IDs are used, SYSTEM IDs are always required [except for notations]).

I realize that I am probably the only person who feels this way.

I prefer this approach because it is the most consistent with the letter and intent of the XML spec and general W3C practice, which is that XML involves Web-based resources. It reflects the ideal (and probably not-to-distaint) world in which network connectivity is omnipresent and ubiquitous.

If the declaration sets are shipped with relative system identifiers then it imposes a specific storage organization that should not, itself, be normative and certainly does not need to be formally defined or required.

Therefore, by using absolute URIs exclusively, there is a clear distinction between the *normative* full names/locations for all resources and the local, for convenience, location of them.

As far as I know, pretty much all tools that users are likely to use, with the possible exception of MS Word (and I haven't looked into it), support one or both forms of catalog.

I have started using this approach in my daily work and so far I'm finding it quite satisfactory.

[This also helps to explain why I have no use for PUBLIC IDs: if you use only absolute URIs there is no useful or practical difference between PUBLIC and SYSTEM identifiers, except that in some cases, the SYSTEM identifiers can be used directly to access resources. In the case where you want to access a local resource you must define a mapping in both cases. Given that XML requires SYSTEM IDs in all cases [except notations, which we don't care about], it's hard to see how PUBLIC IDs add any value and easy to see how they actually complicate things because you have to decide which to prefer (system or public) and configure all your tools appropriately.

Cheers,

E.