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.
Is the problem with the name for glossary.dtd or is it
really glossary.ent and glossary.mod that are the problem?
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?
Do we have the same issue with glossary.xsd?
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"
Changing the PUBLIC IDs or URIs would be an even bigger
deal than changing the filenames.
-Jeff
> -----Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com]
> Sent: Wednesday, September 02, 2009 2:11 AM
> To: dita
> Subject: [dita] Issue: glossary.dtd does not conform
to 1.2 spec
> filenaming rules
>
> It was wrong in 1.1, but it's really wrong in 1.2,
where we're more
> concrete
> about conformance rules for shell DTDs and
vocabulary modules.
>
> The spec is quite clear that topic type modules and
shells should be
> named
> to reflect the topic element type name.
>
> That means the module currently named
"glossary.*" should be
> "glossentry.*".
>
> I realize that just renaming the files would
probably break a lot of
> things.
>
> My suggestion is to rename the files and create
"dummy" versions of the
> originally-named files that simply pull in the
correctly-named files
> via
> entity reference or XSD include.
>
> The catalogs could point to the correctly-named
files since any system
> doing
> catalog-based resolution shouldn't care what the
system ID of the
> resolved
> file is.
>
> This aspect of glossentry has bothered me for a
while, but it caused me
> an
> actual processing problem because I have scripts
that depend on topic
> modules (in particular, the standard-provided
shells) having the same
> name
> as the topic type (in my case, I have a list of
topic type names from
> which
> I can construct the filenames of the shells as well
as the public IDs
> for
> each shell, except for glossentry).
>
> I fixed the problem locally by renaming glossary.dtd
to glossentry.dtd,
> but
> that's not really a sustainable solution.
>
> 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>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave
the OASIS TC that
> generates this mail. Follow this link to all
your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php