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

At 08:36 AM 3/15/99 +1100, Marcus Carr wrote:
>I would be very reluctant to create data in a less intuitive structure
>just to support one possible use of the data [e.g. XSL]. 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.

In general, I agree with the spirit of this (and its expression in your
sig, Einstein's "Everything should be made as simple as possible, but not
simpler." :). 

Actually, though, I think the more granular/atomic the structure, the more
flexibility downstream -- not just for XSL, but for querying and (yes) data
interchange. For applications, it's easy to extract the structured data you
want, even if apparently overly-nested, and ignore those portions of the
structure that you don't... but harder (and needing more hard-coding and
application-specific intelligence) to *add* structure to the source where
it's no better than implicit.


==========================================================
John E. Simpson            | The secret of eternal youth
simpson@xxxxxxxxxxx        | is arrested development.
http://www.flixml.org      |  -- Alice Roosevelt Longworth


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