[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]