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] Issue: glossary.dtd does not conform to 1.2 spec filenaming rules


In the lang ref, in topic.dita, I find a mention of a <glossary> element
(as likewise in the 1.1 lang spec):

<shortdesc>The &lt;<keyword>topic</keyword>&gt; element is the top-level
DITA element for a single-subject topic or article. Other top-level
DITA elements that are more content-specific are
&lt;<keyword>concept</keyword>&gt;, &lt;<keyword>task</keyword>&gt;,
&lt;<keyword>reference</keyword>&gt;,
and &lt;<keyword>glossary</keyword>&gt;.</shortdesc>

 

> -----Original Message-----
> From: ekimber [mailto:ekimber@reallysi.com] 
> Sent: Wednesday, September 02, 2009 6:20 PM
> To: Ogden, Jeff; dita
> Subject: Re: [dita] Issue: glossary.dtd does not conform to 
> 1.2 spec filenaming rules
> 
> 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> 
> 
> 
> ---------------------------------------------------------------------
> 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_workgr
oups.php 
> 
> 


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