Here are some reasons why I prefer the status quo of providing catalogs
using public IDs, in no particular order:
- 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.
- The DITA DTDs are using public IDs for external entities.
Providing catalogs without support for these lookups is just ridiculous.
- 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.
- 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.
- 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.
- Some users cannot count on an Internet connection, whether for
security, performance or connectivity reasons. An absolute,
network-based URL will not work.
- 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.
- 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.
- 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.
|