- From: Bill la Forge <b.laforge@jxml.com>
- Date: Wed, 19 Apr 2000 10:58:30 -0400
- 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: http://www.jxml.com/quick/index.html Bill la Forge
Received on Wednesday, 19 April 2000 10:58:29 UTC