Lists Home |
Date Index |
- From: David Brownell <email@example.com>
- To: "Roldan, Alex" <firstname.lastname@example.org>
- Date: Mon, 14 Jun 1999 08:50:23 -0700
"Roldan, Alex" wrote:
> To me It seems that performing DTD validation on the client and server side
> is an unnecessary overhead. Currently, I am only performing validation
> against the DTD on the server side app. The request and the response are
> both validated by the server app by pre-pending the DTD to the XML document
> before it is validated. The text XML data created by the client does not
> contain the DTD or an external reference to the DTD.
> 1. Is this the right approach ?
If you control both the client and server, and can keep them
always in sync (e.g. you're downloading the client from that
server) so that you don't run into versioning problems.
>From my perspective, both of those restrictions are atypical.
Of course you also have to keep in mind that validation is
only one level of error checking, and it's possible that the
other levels will catch the problems that'd crop up.
> 2. What are the problems I can run into ?
If you write clients for network programs, you learn that
you must not trust servers to perform according to their
specifications ... e.g. a server operated by a business
competitor might very well attempt to subvert clients that
are trusting. It is routine to check the format of data
as it's being imported. (And vice versa -- when clients
send data to servers, the servers shouldn't trust it, for
the same reasons.) Hence the clause above "if you control
both the client and server" -- two different companies
shouldn't take that approach in their client/server code.
Systems are also not static. They evolve over time. The
rules for what is correct/valid change over time. If your
clients have every reason to trust the servers (and vice
versa) you can _still_ run into problems if it's possible
for the protocol versions to be mismatched. Hence the
clause above "and can keep them in sync".
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)