W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2000

Re: Fwd: LOPT: serialization algorithm suggestions

From: Bill la Forge <b.laforge@jxml.com>
Date: Wed, 19 Apr 2000 10:58:30 -0400
Message-ID: <000801bfaa0f$b9e6b840$c8a8a8c0@jxml.com>
To: "Eric Prud'hommeaux" <eric@w3.org>, "Ken MacLeod" <ken@bitsko.slc.ut.us>
Cc: <xml-dist-app@w3.org>
From: Eric Prud'hommeaux
> On Tue, Apr 18, 2000 at 08:20:23AM -0500, Ken MacLeod wrote:
> > This is the crux of the problem.  Without some form of validation of
> > the XML input structure, your C code is going to dereference a pointer
> > and likely core dump if somebody passed you something you didn't
> I'm not proposing that everyone use it or allow it. An aparatus to
> communicate structure could just be used between trusted apps. Or it
> could just core; the supplier of the bad structure could interpret the
> dropped connection as negative feedback. There are plenty of ways to
> get COM to barf, yet it is useful between apps that know what they are
> doing.

The problem I see with most schema-based systems today is that they seem to 
assume that the application code is generated from the schema, which really
limits their applicability.

I'm very pro-schema, but only to the extent that it can be used at a meta level
for validating the input (and references!) and for binding the XML to pre-existing
implementations. OK, I should say binding schema, for clearly the binding is
not part of XML schema, particularly when the binding may be specific to the
application which processes the XML.

(Perhaps the best approach would be to develop binding adjuncts, which augment
schema with such implementation-specific details.)

I think it is important to be able to fully validate incoming XML. I think the goal
should be the ability to offer a service which has some immunity to bad input, and
our concerns should be in making this easier to accomplish.

Here's a crude example of what I'm talking about:

Bill la Forge
Received on Wednesday, 19 April 2000 10:58:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:09 UTC