[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] dita table model
I agree with Paul's analysis. If someone is coming into DITA from another DTD or schema, some changes will be required. If they are coming from a standard DTD, the tool vendors may be able to create an import tool for that purpose. Rob -----Original Message----- From: Michael Priestley [mailto:mpriestl@ca.ibm.com] Sent: Monday, July 19, 2004 7:44 PM To: Paul Grosso Cc: dita@lists.oasis-open.org Subject: Re: [dita] dita table model Thanks for the clarification. Sorry if I jumped too soon on a non-issue. In last week's discussion, wasn't the thought that we should try to provide whatever the widest possible tag set would be, as a base? Admittedly this puts more of a strain on the base transforms, but it would then allow the widest possible range of variations through specialization. Michael Priestley mpriestl@ca.ibm.com Dept PRG IBM Canada phone: 416-915-8262 Toronto Information Development Paul Grosso <pgrosso@arbortex To: dita@lists.oasis-open.org t.com> cc: Subject: Re: [dita] dita table model 07/19/2004 09:08 PM At 17:47 2004-07-19 -0500, Paul Grosso wrote: >At last week's telcon, during the discussion of what table model to use >in DITA, it was suggested that forcing users to use a particular table >model will discourage users who are already standardized on a different >model. > >DITA is a DTD, so right off we are constraining users by defining a >vocabulary they must use. DITA goes to greater extents than most other >vocabularies to provide a controlled way to extend the vocabulary, but >within fairly limited bounds that ensure the benefits of a known >vocabulary are not entirely lost. > >DITA's extension mechanism maintains most of the benefits of a known >vocabulary by ensuring that the XSLT already written for the known >vocabulary will work for newly defined tags. > >Doing something like this for disparate table models would be very >difficult. Just to clarify: when I said "doing something like this for disparate table models" I didn't mean one couldn't use specialization on table tags. I meant that one couldn't expect--as one does with specialization-- that one could plug an arbitrary table model into the DITA vocabulary and have it work in the existing stylesheet and tools. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]