Cart
[Home] [By Thread] [By Date] [Recent Entries]
Actually there is another representation of the information in the DTD that is present: the application that uses the document. Unfortunately the representation is in C++, Java or some other language. This introduces a synchronization problem between the two. The DOM api for instance gives you access to the parsed document tree, but a sizable amount of independent code must be written to essentially parse the DOM tree into the form the application needs. The result is the structure is in 2 different forms, declarative and procedural, which must be kept in sync. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com ---------- From: len bullard [SMTP:cbullard@h...] Sent: Thursday, March 11, 1999 9:24 PM To: Didier PH Martin Cc: 'XML Dev' Subject: Re: FW: Namespaces and DTDs Didier PH Martin wrote: > > Hi > > I am using these simple rule of thumb: > > a) a XML DTD is useful for XML editors not for XML renderers > b) Most XML renderers (XSL, CSS or DSSSL won't do document validation) > c) a XML interpreter do not need a DTD (something else than rendition) > > If I need a DTD at the receiving end, then I am now no longer in the XML > world but in the SGML world because the receiving end needs a validating > parser. Several SGML parser like for instance SP can parse XML simplifyed > DTD. The only simplification I gained is the -- or -0 think called omitags. > Therefore, because I have to include a DTD for validation, better use then a > SGML format. > > However, on the Web, to reduce complexity, I should not assume that the > receiving end has a validating parser. Thus, because my XML document has > been validated with my XML editor or by any other validation program. The > receiving end makes the reasonnable assumption that if the docuement is a > XML docuement it is "well formed" and valid. That's mostly true because web documents don't stick around. In cases where information is moving across multiple processes or sits in some long term archival, it is very handy to be able to validate it on the receiving end. This will become more apparent to the XML community when they get to do the sort of work the SGML community did a decade after the first SGML applications fielded instances. Things change. Finding those changes quickly is the key to cheap rehosting. In my experience, if DTDs die, someone gets to reinvent them and it will be painful. Otherwise, yes, the DTD is much more useful in the editor in the initial part of the information lifecycle. len > xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
