xml-dev - Re: designing the XSLT

[Eric Bohlman <ebohlman@netcom.com>]

On Thu, 27 Jul 2000, Raheja, Dhruv  (TRANS) wrote:

>      i have prepared the DTD and XML for my application. i am having some
> problems deciding how to structure the XSL  and i'm hoping someone will be
> able to guide me. my  design objective for the XSL doc is that it should be
> a generic doc that i can apply to applications (in my case i'm trying to
> design tech manuals using XML) that have the same make-up or XML/DTD
> heirarchy. i guess to make things easy for the time being i could design the
> XSL in such a way that it suits my prototype document but it would obviously
> be more beneficial if i could design a generic XSL that would cater to all
> the manuals that are are authored using XML. on similar lines, i have
> designed a more-or-less "generic" DTD and XML. the basic problem is that my
> DTD is rather loosely structured just so that it can be applied to any
> similar XML document.  e.g. i have the declaration:
> 
> <!ELEMENT activity (schematic | outline | text_description |
> visual_description | procedure | note | warning | caution)*>
> 
> as you can see, any element can pretty much appear in any order and any
> number of times. e.g.  i could have  <visual_description> before a
> <procedure>  or  say before a  <text_description> and i could have multiple
> ocurrences of <visual_description>. the case is the same with <note>,
> <warning>, <caution> etc. 
> 
> this is causing a problem to me when i try and design/conceptualize a
> generic XSL because although the elements could be the same for all XML
> docs, their order/inclusion could be different for each doc. how do i
> overcome this problem? what functionality of XSL (e.g. commands) would be
> best for designing such an XSL doc? 

This isn't a problem at all if you think in terms of the declarative,
rather than procedural, aspects of XSLT.  You write templates for each
element that can be a child of <activity> and then you write a template
for <activity> that outputs any "beginning" stuff for an activity, then
does an <xsl:apply-templates>, and then outputs any "ending" stuff for the
activity.  The apply-templates instruction causes the XSLT processor to go
through the child elements of <activity> and process them according to the
appropriate templates in the order in which it encounters them.  The point
is that you don't have to write code to handle the sequencing; it's all
built in to the XSLT processor.