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


-----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
Dept PRG IBM Canada  phone: 416-915-8262 Toronto Information Development


                      Paul Grosso

                      <pgrosso@arbortex        To:
                      t.com>                   cc:

                                               Subject:  Re: [dita] dita
table model                                             
                      07/19/2004 09:08



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

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.


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