>Now that it is more often used as a data interchange medium it is >often no longer sufficient to rely on this internal mechanism for >specifying the DTD.
Disagree. This makes it more important than ever that the document clearly identify how its contents were intended to be interpreted -- including any defaults and datatypes. >For this to be safe it must be guaranteed that the correct DTD >is used, namely the one that defines the format the application >can handle. Agreed, with slight modification: For this to be _safe_, the document must be one that the application is prepared to handle... which means it must be written using one of the DTDs which this application knows about. That doesn't mean "in accidental conformance with" that DTD or schema; it means _intended_ to be interpreted per those semantics. And if that's your intent, you might as well say so in the document. Leaving it unspecified makes the document more loosely defined, which will allow you to shoehorn it into more applications... but which will also result in it being accepted erroneously more often. Re schemas as an analogy: Unfortunately, schemas are applied at a different layer of XML processing than DTDs are. DTDs are part of building an infoset; schemas are defined as being applied to an infoset to check it and transform it into a post-schema-validation infoset. I'm not wild about that situation, but that's what we've been given to work with. Note that it's possible -- though probably undesirable! -- to have both a DTD _and_ a schema contributing to the content as seen by the application. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
