Re: XSL-optimized DTDs (Was: Re: Mixed content: selecting cu

John E. Simpson wrote:

> For instance, consider a scheduling application whose root is a calendar
> element:
>         <!ELEMENT calendar (year)+ >
>         <!ELEMENT year (month)+ >
> If left this way, when you actually have to transform a document instance
> into (say) HTML, you've got to do all sorts of first-of-type and
> not(first-of-type) exception processing for the for-each loops that build
> tables, lists, and so on. The XSL will be much cleaner if you can use this
> sort of structure instead:
>         <!ELEMENT calendar (years) >
>         <!ELEMENT years (year)+ >       <!-- "wrapper" for multiple years -->
>         <!ELEMENT year (months) >
>         <!ELEMENT months (month)+ >     <!-- "wrapper" for multiple months -->

My personel feeling is that I would be very reluctant to create data in a less
intuitive structure just to support one possible use of the data. I would be much
more inclined to structure it as cleanly as possible and worry about how the data
is going to be handled when the time comes. If you're operating in a closed loop
then your approach would be fine, but if you will need to interchange with anyone
else, they're probably just going to think that your structure is over-defined. My
vote is for more work in the XSL and less complexity in the data.


--
Regards,

Marcus Carr                      email:  mrc@xxxxxxxxxxxxxx
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list