SGML: Common Telecom DTD - and TCIF

Common Telecom DTD - and TCIF

Subject: Re: Common Telecom DTD
Date: Thu, 22 May 1997 16:46:13 -0700
From: "K. Meusel" <>
Newsgroup: comp.text.sgml
-------------------------------------------------------------- Per-Ake Ling wrote: > > Per-Ake Ling wrote: > > > > Peter Flynn wrote: > > > > > > Paul, Madsen wrote: > > > > > > > > Hello, does anyone have any information on the Common Telecom DTD (CTD). > > > > > > > > I believe it is the European counterpart of the TCIF TIM DTD. > > > > > > No, but I'd be very interested to know if you find either of them. > > > > Since there is a good post from my colleague from Siemens > (Henning Moeller) regarding CTD and addresses for further info > about EFTI3, I will here limit myself to forward the answer > I recieved from Don Pratt in TCIF: > > <!--*Updates, related files, and documentation will be available at: > > Additional sites for downloading: > (command-line ftp only) > (accessible with Web browsers) > TIM 2 is defined and described in TCIF-IPI-95-004, Issue 2. > To order, please contact TCIF, 202-434-8844.*--> > > -- > Per-Åke Ling email: > Ericsson Utvecklings AB phone: +46 8 727 5674 > AXE Research and Development fax: +46 8 727 3247 Now, given some entry points to EFTI's CTD and TCIF/IPI's TIM DTD, we should try to identify what they (might) have in common and where the differences are. As far as I understand it, the DTD's complement each other. However, my knowledge about TIM is poor, so please take my statements below as "opening shot" & add your comments on the TIM-side. As stated in my abstract about the CTD (which has been posted by Henning, because I had problems with the newsreader) the CTD offers both specific contents-based structures for operation and maintenance documentation and generic text structures in a scaleable way (-> semantic level, granularity, ... ). A design principle for the contents-based ("semantic") structures and the telecom-specific set of elements within the CTD was to build the intersection of structures and elements within different vendor's and operator's documents (as far as possible). Therefore, the CTD may be regarded as restrictive in these specific parts. On the other hand, this approach allows customers/people processing documents which are compliant to the CTD to hook in powerfull tools for configuration, automatic linking, etc. As far as I know, parts of the TIM DTD are very open. Instead of building the intersection of structures and elements, it offers the union, i.e. offers different optional sub-structures and puts them together with "OR"-connections. This approach is open, but restricts potential engineering-methods / a further document processing. What about the operator requirements concerning TCIF/TIM ? What are US customers intending when requesting documentation in compliance with the TIM DTD ? If the DTD is just used to exchange turn-key solutions from A to B, why is important to have a single DTD ? Answers/comments are highly appreciated and would help to find the right balance in this trade-off. Best regards -- KM email: