Altova Mailing List Archives


Re: Does DTD validation work with namespaces?

From: Rick JELLIFFE <ricko@--------.--->
To: xml-dev@-----.---.---
Date: 8/14/2000 10:04:00 AM
"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

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.