OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


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

From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Monday, January 24, 2005 8:49 AM
To: Christopher Wong
Cc: DITA TC list; Don Day
Subject: Re: [dita] Catalog files as part of the submission?

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
Dept PRG IBM Canada  phone: 416-915-8262
Toronto Information Development

Christopher Wong <cwong@idiominc.com>

01/24/2005 11:46 AM

Don Day <dond@us.ibm.com>
DITA TC list <dita@lists.oasis-open.org>
Re: [dita] Catalog files as part of the submission?

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]