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

[ekimber <ekimber@reallysi.com>]

On 9/2/09 4:53 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

> I'm inclined to think that we've lived with the inconsistency between
> glossary and glossentry for a couple of years now without serious
> problems, so we can probably ignore it for DITA 1.2 and deal with it, if
> it needs to be dealt with at all, as part of DITA 1.3.

Fair enough, if that is the consensus of the TC. I bring it up because it's
a rather obvious bug made more obvious by our new language around vocabulary
module coding rules.

If it caused me an implementation difficulty it will almost certainly cause
others implementation difficulties.

> Is the problem with the name for glossary.dtd or is it really
> glossary.ent and glossary.mod that are the problem?

It's primarily with the modules--the spec currently doesn't require shells
to have any particular name, although the convention of making the shell the
same as the topic type is pretty well established.
 
> If I create a new map or topic doctype shell that reuses an existing
> type, but includes a different set of domains or does something
> different in terms of topic nesting, do I have to use the same file name
> for the new shell's DTD?  How can that work?

You put it in it's own directory.

You should never, as a matter of practice, be putting local shells in the
distribution directory for the TC-provided shells.

If you're using the Toolkit to manage all your doctypes, then the easiest
thing to do is to create a plugin with your local shells, which keeps things
clearly separated and automates management of the master catalog.

This does require that you always refer to your shells by public ID,
absolute URL or URI, or by a relative path that gets to the right place.
Simply having "concept.dtd" map to a particular shell would not be good
practice.
 
> Do we have the same issue with glossary.xsd?

Yes.
 
> In addition to the file name, is there a problem with the PUBLIC IDs and
> URIs that we use:
> 
>  
> 
> PUBLIC "-//OASIS//DTD DITA Glossary//EN"
> 
> PUBLIC "-//OASIS//ELEMENTS DITA Glossary//EN"
> 
> PUBLIC "-//OASIS//ENTITIES DITA Glossary//EN"
> 
>  
> 
> URI "urn:oasis:names:tc:dita:xsd:glossary.xsd"
> 
> URI "urn:oasis:names:tc:dita:xsd:glossaryMod.xsd"

We wouldn't have to change these (they would need to still resolve to my
proposed "shell" versions of those files that then pull in the
correctly-named versions.

We would need to new public IDs and URIs for the correctly-named versions of
these modules. Users using the old names would be unaffected (at least in
1.2). Users starting from scratch could of course point to the
properly-named versions directly.

Thus change, if done this way, wouldn't break any existing tools.

Note that we can *never* in 1.x define a topic type called "glossary" since
that name is already taken, so if we want to define a topic type that is a
collection of glossary entries and glossary groups, we'd have to call it
something else.

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>