OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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


Subject: RE: DOCBOOK: reasoning behind index terms


By different content models, I mean that primarie and secondaryie might allow different elements, if that were representative of their meaning.

For example, take a look at section and simpleSect. They largely do the same thing, but they *do* have different content models, as they mean different things. As an aside, I'm a big fan of this approach in docbook. A recursive structure that can act as both a non-terminal and a terminal plus an additional stucture that is a terminal is very cool.

My view on the XSLT cost is this: 
- you are accepting a greater cost in the schema change
- there are likely some significant costs elsewhere in your system, such as migration or downstream process
- Any XSLT developer can make this type of change very quickly

Rich

-----Original Message-----
From: Matthew L. Avizinis [mailto:mla@gleim.com] 
Sent: Monday, August 05, 2002 8:43 AM
To: Richard Lander; docbook@lists.oasis-open.org
Subject: RE: DOCBOOK: reasoning behind index terms


thanks for your input.  Further comments inline.
matthew l. avizinis

> -----Original Message-----
> From: Richard Lander [mailto:rlander@microsoft.com]
> Sent: Monday, August 05, 2002 11:15 AM
> To: Matthew L. Avizinis; docbook@lists.oasis-open.org
> Subject: RE: DOCBOOK: reasoning behind index terms
>
>
> In the case of indexes, it seems to me that a more formal structure, 
> such as the one that is currently implemented in docbook, is 
> attractive. I know that the indexers here would certainly agree with 
> that. Do you really want to go eight levels deep in an index? In 
> addition, the use of unique elements allows for different content 
> models, which might be needed given that indexers seem to think about 
> each level somewhat differently. In short, I think that your 
> co-workers are wrong. In the case of TOC and sections, recursive 
> structures are the better way to go, IMHO.
2-->This seems to be getting at what I am after, but I don't quite know what you mean by "different content models".
>
> The XSLT doesn't have to be any longer. Your template can match 
> multiple elements, then calculate the level, or use a choose ...
2-->Yes, I showed this.  However, their argument for simpler code is based on the assertion that "if" we wanted to add a fourth level then we'd have to change the XSLT code with an explicit index naming scheme whereas the other method might not require any change to the code at all.  My contention is that even if that is true, the changes would be virtually trivial.

>
> Thanks,
>
> Rich
>
> -----Original Message-----
> From: Matthew L. Avizinis [mailto:mla@gleim.com]
> Sent: Monday, August 05, 2002 7:37 AM
> To: docbook@lists.oasis-open.org
> Subject: DOCBOOK: reasoning behind index terms
>
>
> Hello,
>   What is the reasoning behind using all the index, indexdiv, primary, 
> secondary, indexentry, etc. terms? (Is there a link to a webpage that 
> already addresses this issue perhaps?)  A debate at my office has one 
> side supporting the docbook terminology and the other stating that 
> <index>
>   <item>
>      <item>
>         <item>
>            etc.
>         </item>
>      </item>
>   </item>
> </index>
>
> would be simpler to use with XSLT, i.e. any code would be shorter and 
> less repetitive.  I, for one, am in favor of the more descriptive 
> approach used by docbook.  However, perhaps I do not able to state my 
> reasons eloquently enough to convince them that it has more advantages 
> than the above method. So, could someone describe a few reasons why 
> DOCBOOK uses the terms it does for indexing and perhaps show some of 
> the disadvantages of the above scheme. thanks for all help,
>    Matthew L. Avizinis <mailto:mla@gleim.com>
> Gleim Publications, Inc.
>    4201 NW 95th Blvd.
>  Gainesville, FL 32606
> (352)-375-0772
>       www.gleim.com <http://www.gleim.com>



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


Powered by eList eXpress LLC