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

Hi John,

John E. Simpson wrote:

> Yah. In FlixML ver. 3.0 (not yet available on-line), I've done pretty much
> just that (ATTLISTs omitted for brevity):
>   <!ELEMENT cast        (leadcast, othercast?) >
>   <!ELEMENT leadcast    ((male | female | animal)*) >
>   <!ELEMENT othercast   ((male | female | animal)*) >
>   <!ELEMENT male        (castmember, role)* >
>   <!ELEMENT female      (castmember, role)* >
>   <!ELEMENT animal      (castmember, role, species)* >
>   <!ELEMENT castmember  (#PCDATA) >
>   <!ELEMENT role                (#PCDATA) >
>   <!ELEMENT species     (#PCDATA) >

Just out of interest, what do you do if a castmember has multiple roles and/or
crosses gender and/or is genderless? Also, if you are able to have multiple male
| female | animal elements in leadcast or othercast, then why do they allow
multiple castmember and role elements? It would seem that the following would be
legal:

<othercast>
   <male>Bill Bob</male>
   <male>Phil Bob</male>
   <male>Tim Bob</male>
</othercast>

<othercast>
   <male>Rob Bob</male>
</othercast>

<othercast>
   <male>Fred Bob</male>
</othercast>

<othercast>
</othercast>

Would it not be better to restrict the structure in order to introduce more
predictability? Content models such as:

<!ELEMENT othercast   (male | female | animal)+>
<!ELEMENT male        (castmember, role)>

would deliver the same results with much less complication. Could this be one of
the contributing factors to your XSL being difficult?


--
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