Re: [dita] Issue: glossary.dtd does not conform to 1.2 specfilenaming rules

[ekimber <ekimber@reallysi.com>]

On 9/8/09 10:07 AM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> Eliot, you are correct.
> 
> I should have said that it is a good practice to use different file
> names for different shells. Using unique names reduces the chance of
> confusion, it allows different people or different organizations to
> organize their DITA files differently without creating conflicts, and it
> allows the DITA TC to organize things differently from release to
> release without having to worry about name conflicts.

Hmm. I think we're talking about two different domains: TC-defined shells
and user-created local shells.

In the first case I agree that all shells for the same topic type need to
have distinct names since it is certainly possible that the TC might want to
package all the DTDs into a single directory (although that wouldn't be my
preference).

In the case of local shells, I would say it's really a function of how you
manage and deploy your declarations. As far as I can tell, the easiest way
to manage and deploy them is to use the Open Toolkit and manage them as
plugins, which serves to both keep them organizationally distinct and
manages all the catalog integration for you, providing a single point of
management for all tools that can use arbitrary catalogs.

In that case, the filenames of the shells don't really matter because the
public IDs are much more important, as are the names and organizations of
the plugins themselves (e.g., com.reallysi.doctypes as the name of our
plugin that manages our local shells).

If one assumes that users will use template documents or other editor
features to create new documents, they don't really ever think about the
shell name, but focus on the topic type itself. That is, somebody creating
an RSI-specific concept topic knows to pick the RSI-specific concept
template and knows they're creating a topic, but they don't really know (or
even have a basis for understanding) that they're using a specific
configuration of concept.

But I can see that others might have existing methodology for working with
declarations or there might be tools that impose constraints on how
declaration sets are organized. If somone wants to put all their shells into
the same directory as the TC-provided shells, we can't tell them that's
wrong.

In any case, I don't think that for shell DTDs we can either impose
constraints or define a suggested convention or best practice--there's too
much need for variation to accommodate different ways of organizing and
deploying shells.

For modules the naming conventions are important and there can never be
naming conflicts for modules developed with knowledge of each other (and
creators of local modules should take care to make their module names
reasonably well qualified to avoid conflicts with independently-developed
modules).

Cheers,

E.

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>