[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Version numbers for public IDs for non-shell DTD components
Hello Robert, Once we have an approved design proposal for #12001 (versioning in the catalog/dtd), it might be useful to discuss among the TC whether this feature can be fast-tracked. Perhaps it would be possible to produce a fully versioned set of the DTDs as as a minor release, errata or test suite. Yas Etessam Consultant, XMetaL JustSystems Inc. > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Wednesday, May 30, 2007 6:08 AM > To: dita@lists.oasis-open.org > Subject: Re: [dita] Version numbers for public IDs for > non-shell DTD components > > When we added the version specific IDs initially, it was only > done for the DTD files. The thought was that a tool could use > a catalog to load the DTD itself, but then use the relative > path inside the DTD to load each module. > So, once dtd_1.1/topic.dtd is loaded, you can load topic.mod > from the same folder. This would require trimming down the > catalog, as well as a tool that can load files based on the > relative path. > > Others have had problems with this as well, and this is > expected to change for DITA 1.2 - the DTD itself will use > version specific IDs for each module, and the catalog will > contain IDs for each version. > > Robert D Anderson > IBM Authoring Tools Development > Chief Architect, DITA Open Toolkit > (507) 253-8787, T/L 553-8787 > > > > > "Chris Wong" > > <cwong@idiominc.c > > om> > To > > <dita@lists.oasis-open.org> > 05/30/2007 08:02 > cc > AM > > > Subject > [dita] Version numbers > for public > IDs for non-shell DTD > components > > > > > > > > > > > > > > > > > I'm sure we must have covered this before, but I just > reviewed the catalog.xml in the DITA 1.1 draft and and was > surprised to find that many public IDs don't have the version > number embedded in it. This is a problem for any > implementation that needs to support different DITA versions. > The catalog approach would have addressed this elegantly. For > example, the entries for the shell DTDs direct the parser to > the appropriate DTD version based on the public ID in the > DOCTYPE declaration: > > <public publicId="-//OASIS//DTD DITA 1.1 Topic//EN" > uri="dtd_1.1/topic.dtd"/> > <public publicId="-//OASIS//DTD DITA 1.0 Topic//EN" > uri="dtd_1.0/topic.dtd"/> > > But the shell DTDs in turn load their *.ent and *.mod > components, and those have unversioned public IDs: > > <public publicId="-//OASIS//ELEMENTS DITA Topic//EN" > uri="dtd_1.1/topic.mod"/> > So a document with a DOCTYPE pointing to DITA 1.0's topic.dtd > would load dtd_1.0/topic.dtd, but will load topic.mod from > dtd_1.1/, simply because topic.dtd does not ask for a > specific version of topic.mod and gets whatever the catalog > provides. Am I missing something? > > Thanks, > > Chris > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]