[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] problem with packaging of glossaries
There are several related issues here that we need to separate
out in our discussions: 1.
What is the folder/file structure and what names do we use when
we distribute the DITA DTDs and XSDs? 2.
What Public identifiers and what URIs do we use to reference the
various components? 3.
What doctype shells do we distribute, what domains do they
include, and what topic nesting do they allow? 4.
How may packages (.zip files) do we create and what goes in each
one? 5.
How is the written DITA 1.2 specification organized? I think, but am not completely sure, that our recent discussion
of glossaries (and concept, task, and reference) has been about item #4
(packages). Can someone confirm that? We did talk about all of this quite a bit many months ago, we
finally came to a consensus, and voted to accept a solution back then. At
that time there was a feeling on the part of some that DITA was perceived as
being very “techdocs” oriented and creating separate packages, including
the Technical Content “package”, was one way to address that and to
give other collections of specializations more visibility. At that time there
was also the concern that Michael reminded us about that DITA was already quite
large and was getting larger and that we needed to organize things in a fashion
that managed that complexity. For me items #1 and #2 are much more important to than #3 and #4.
I think we’ve got the folder/file structure, names, Public identifiers,
and URIs in pretty good shape now, so I hope we don’t make any changes to
#1 and #2 at this point. I’m more open to changes to #3 and #4,
although this late in the DITA 1.2 cycle I guess I’m somewhat in favor of
limiting changes as much as we can. I really don’t think that there is
any single solution to #3 and #4 that will meet everyone’s needs and so I
expect that we will revisit the question of what is included in #3 and #4 at
fairly regular intervals well into the future. As far as #4 (packages) goes, right now I think we are taking
the approach that there isn’t any overlap or duplication between the
packages except for the “everything package”. That means that
unless you are using the everything package or just need the base package, you
will need to combine two or more packages. We could take a different
approach to packaging and allow duplication and overlap between packages, so that
each package would be complete and self-contained. That would allow us to
include glossary (and concept, task, reference) in several packages, but
allow us to keep the folder/file structure as it is with a fairly small
collection of things in the “base” folder. We would still need to
figure out what is and what isn’t included in each package, but to the
extent that we have a sub-committee for each package, we might be able to ask
them to tell us what needs to be included to make their packages most useful. -Jeff From: Kristen James Eberlein
[mailto:keberlein@pobox.com] Two key issues:
Best,
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]