"Winchel 'Todd' Vincent, III" wrote:
 
>  When I say, "new behavior rules" I do not mean you could simply allow new
>  elements to be inserted into a well-formed document, from a different
>  namespace, when you have this:
>  
>  <!DOCTYPE Address [
>  <!ELEMENT Address (Street+,City,State,PostalCode,Country) >
>  <!ELEMENT Street (#PCDATA) >
>  <!ELEMENT City (#PCDATA) >
>  <!ELEMENT State (#PCDATA) >
>  <!ELEMENT PostalCode (#PCDATA) >
>  <!ELEMENT Country (#PCDATA) >
>  ]>
>  
>  That is, you can't do this:
>  
>  <Address>
>   <H1>This is what I unilaterally decided to put here today.</H1>
>   <Street>2356 Peachtree Street</Street>
>   <City>Atlanta</City>
>   <State>Georgia</State>
>   <PostalCode>30302</PostalCode>
>   <Country>U.S.A.</Country>
>  </Address>
>  
>  I would not want to allow the insertion/mixing of <H1> either if the
>  "Address" DTD were mine.
>  
>  However, if the "parent" DTD (for lack of a better word) were to allow ANY
>  in one or more places, then you could add otherwise undeclared elements from
>  a different namespace where ANY content is allowed (along the lines of what
>  I suggest to Marcus).  This would allow you to use elements from someone
>  else's DTD without having to create one big DTD and you might also be able
>  to take advantage of some of the Namespace features (defaulted prefixes, for
>  instance), which I can't see how you would do otherwise.
>  
>  Again, I could be way off base on this, but I'd appreciate any feedback.

XML Schemas seems to allow exactly what you are asking for: a wildcard
particle that lets you open up to different namespaces. (Note that XML
Schema's type derivation mechanism is not relevant here: extensions of
types are tacked on at the end of content.)

Schematron also allows this kind of thing easily.

If you are asking: is it possible to use DTD syntax to specify some
other set of constraints on top of the ones expressed in the usual DTD,
then that road has already been gone down: ISO Architectural Forms allow
you to declare markup declarations in an external entity. These
declarations are interpreted according to different rules than normal
DTDs, which can allow some special effects.

Finally, you can simply transformat your instance through XSLT into
various forms, and check these against specific DTDs. 

So you already have these four choices:
  1) Schematron: here now, small, not standardized, not shrink-wrapped
  2) XML Schemas: real soon now, big, to be vendors-standard, to be
shrink-wrapped
  3) Architectural Forms: here now, medium but hard to understand, ISO
standard, not really shrink-wrapped
  4) Transform: here now, medium complex, non-standard,
not-shrink-wrapped.  


Rick Jelliffe