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

At 10:34 AM 3/15/99 +0000, Guy_Murphy@xxxxxxxxxx wrote:
>One way of dealing with this, which I'm not advocating is necessarily the
>best way, merely another tool in the kit, is when one has a basic logical
>unit represented as a tag, who's general use is straightforward, but that
>may convey extra meaning underster certain circumstance, is to extend the
>logical unit into several using attributes.

Yes, that's a good quick-and-dirty approach -- another tool in the kit, as
you say. And with XSL match/select syntax and transformation, the values of
attributes need be no more invisible to an application than PCDATA element
content. But I've never been able to get past my sense that it's, well,
cheating to "hide" content and structural information in attributes.
There's nothing structural about attributes as such; they're merely
decoration for the actual document scaffolding. So if a thing (like a name,
in your example) may logically be said to consist of two or more sub-things
(like givenname and surname), I think one must swallow hard and opt to
codify this structurual logic in the DTD.

Of course, as I said to Marcus in another message on this thread, my
intention with FlixML is to make it "complete" rather than "bullet-proof."
The breakdown of a person's name into given and surname pieces seems like a
natural enough extension, but doesn't strictly speaking apply to names in
many non-Western cultures (especially when one thinks of "given name" as a
synonym for "first name"). Rather than deal with all that, in FlixML I just
ducked the whole issue <cough/>.

>Just my 2p worth :)

And thanks to the miracle of compound interest, it's already doubled in
value. :)

=============================================================
John E. Simpson          | It's no disgrace t'be poor, 
simpson@xxxxxxxxxxx      | but it might as well be.
                         |            -- "Kin" Hubbard


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