FW: Namespaces and DTDs

[Marc.McDonald at Design-Intelligence.com]

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 at hiwaay.net]
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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following 
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)