Subject: Re: XSL-optimized DTDs (Was: Re: Mixed content: selecting current context w/out child) From: Marcus Carr <mrc@xxxxxxxxxxxxxx> Date: Mon, 15 Mar 1999 13:54:18 +1100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL-optimized DTDs (Was: Re: Mi, John E. Simpson | Thread | Re: XSL-optimized DTDs (Was: Re: Mi, Guy_Murphy |
Re: XSL-optimized DTDs (Was: Re: Mi, John E. Simpson | Date | Re: XSL-optimized DTDs (Was: Re: Mi, Marcus Carr |
Month |