I think Michael should insert a conref to the catalog in the spec. :-)
Too bad content reuse does not extend to heterogenous content models.
Seriously, I think it makes sense to have the catalog be the normative
mapping of public IDs and for the spec to just refer the reader to the
catalog. It seems consistent with what we are doing right now with DTDs
and schemas.
Chris
Yas Etessam wrote:
There's extra maintenance if you need to keeping
the spec synchronized with the catalog.
My two cents is that the spec should direct
users to the catalog files for information on mapping public ids and
could just provide an example of how system or public identifiers could
be used to identify DITA instances.
- Yas Etessam
If we provide the catalog, do we
still need to document the identifiers in the spec, or does the catalog
just become part of the spec? IE, can the spec document proper simply
refer to the catalog as one of the accompanying documents, without
repeating its contents?
Michael Priestley
mpriestl@ca.ibm.com
Dept PRG IBM Canada phone: 416-915-8262
Toronto Information Development
Don Day wrote:
> Are catalog files (both text and OASIS XML forms) necessarily part
of
> the DTD/Schema submission for the proposed Committee Draft? If so,
> I'll add them to the "dtd/schema" package after we update the
public
> identifiers. I do not think they are normative, but I could be
> convinced to include them. I think they tend to be
> application-specific and merely encode information that is already
in
> the DTDs. However, it is tremendously useful for them to be
present in
> a distribution so that users can configure their local lookups.
>
Since the DITA DTDs are themselves using public IDs (external parameter
entities), I think it makes sense to provide catalogs for the lookups.
Chris
|