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

John E. Simpson wrote:

> "Yeah, all right, I could have
> broken the animal element up into male and female as well. I had to draw
> the line somewhere -- I was just trying to teach XML, not cover the
> fraction of a percent of movies with animal cast members of both genders!" :)

That sounds perfectly alright to me. I can't think of a single situation where
the gender of the animal would be relevant to me - I'm reasonably confident that
this will remain true throughout my lifetime... :-)

> >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>
> ></othercast>
>
> Maybe I'm misreading something (always a possibility), but I think the
> first and second example would be illegal because <male> doesn't have
> PCDATA content. You're right about the third, though, and I need to plug
> that gap (also the possibility that <male>, <female>, and <animal> can be
> legally empty). Thanks for the catch.

No, sorry, that's just me being sloppy first thing in the morning - I should have
included the rest of the elements in <male>. The real point is that if you can
rely on your document having exactly one occurrence of the <othercast> element
and a minimum of one <name> element inside it, you may find that it provides you
enough information to simplify your XSL.

> I love finding out about these kinds of bugs in the DTD (and there are
> others, known as well as yet unknown). OTOH I'm reluctant to make it *too*
> rigorous; it is, after all, basically just a demonstrator rather than a
> "real" application, and to the extent that it incorporates a variety of
> structures -- even "slack" ones -- I'll be able to use it to demonstrate a
> corresponding variety of circumstances. And on yet another hand, I don't
> want to be embarrassed about it. :)

I certainly wouldn't say that there's anything to be embarassed about - as soon
as someone figures out how to blindly define best practice, most of us will be
out of a job. If you were converting to XML automatically from something as
structured as a database, there may not be too much to gain from a very tight
structure, provided you could query and format the data. If this was an authoring
DTD, I'd be inclined to tighten it as it would offer a bit more help to the
authors by reducing choices. I personally prefer to start with rigid DTDs, but
much of that is aimed at making sure that changes tend to be backward compatible.



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