Sorry for the silence. I took a couple of days off.

True schema validation is an extremely expensive process -- especially
if you put uniqueness or referential integrity constraints into the
schema. Even checking for nulls can be expensive if it's a large
document instance. If you have control over the client environment and
know that the client will send only valid messages, then it absolutely
doesn't make sense to validate all incoming messages.

Also, in some circumstances, you may want to allow systems to add
extraneous information or change a type or whatever for extensibility
reasons. After all, XML is supposed to be extensible.

Validation should be performed only when explicitly requested.

As I said in my original response, a databinding framework will always
perform some basic validation -- it's expecting to get a particular
XML structure that it knows how to map to a particular object graph.
If you feed it an unexpected XML structure, it will barf. That's not
the same a validation, though. Is it appropriate to check for valid
nulls during data binding? Enumerations? Regular expression formatting
constraints? Maybe. But where do you draw the line?

Anne

On 7/12/06, Doug B <[EMAIL PROTECTED]> wrote:
Anne doesn't appear to be around right now, but I'll bug her when it
looks like she is.  In the meantime, surely some of the other list
readers have some opinions on this topic?

On 7/9/06, Benjamin Fan <[EMAIL PROTECTED]> wrote:
>
> If there is going to be a discussion then I would very much like to
> participate in it. I am in the middle of building a production system where
> I do in fact need to validate against the schema. In fact the WSDL (doc
> literal) will form the basis of a commercial interface specification for 3rd
> parties. They will not be Java.
>
> Best Regards,
>
>
> Benjamin Fam
>
>
>
> On 7/10/06, Doug B <[EMAIL PROTECTED]> wrote:
> > <warning: long, "best practice" questions to follow>
> >
> > Interesting to hear you say that, Anne.  I've been on a multi-year
> > quest to get automatic, fast validation out of a Web Services engine.
> > Conceptually, it always seemed like the "right" approach (especially
> > for Document-Literal).  If you're having to parse XML anyway, and your
> > XML parser can validate when it does so, why not do it, actually
> > enforcing your restrictive WSDL/Schema at the layer that defines and
> > understands it?
> >
> > At the time, Axis did not do this at all, but my Bugzilla feature
> > request seemed to get agreement that this was a good goal:
> >
> > http://issues.apache.org/jira/browse/AXIS-222
> >
> > Also at that time, I tried out Systinet Wasp, which did do
> > auto-validation.  Much later, I came across the DeveloperWorks article
> > about combining Axis and Castor to get auto-validation:
> >
> >
> http://www-128.ibm.com/developerworks/webservices/library/ws-castor/
> >
> > This approach was exactly what I was seeking, so we started using it.
> > It's very simple, but it does seem slow.  (I'm also not getting pure
> > POJOs for my "schema" beans, which I'd really like, but Castor's
> > aren't too bad.  Haven't found an XML framework that generates clean
> > POJOs from a schema and don't want to write mapping files if I can
> > help it.)
> >
> > Along the way, we asked everyone we could whether or not
> > auto-validation was a good approach, and we got responses all across
> > the spectrum.  Clearly some people expect and want it, but others
> > don't.  Some engines can do it, but others can't.  If the only reason
> > not to do it is performance, will the newer parsers or something like
> > JiBX make a significant difference?  What if you have access to an XML
> > appliance?  Would more people do it in that case?  I suppose an engine
> > that let you enable and disable it at will would be nice.
> >
> > I'm not exactly sure where I stand at this point, but I'm not quite
> > willing to give up on the "dream".  That is, the dream of wholly
> > specifying my interface via WSDL/Schema, and having a WS engine
> > completely wrap, translate, and validate
> > requests/responses/exceptions, hiding from my business code the fact
> > that it's even being accessed as a Web Service, but ensuring that
> > anything that comes through the Web Service interface doesn't violate
> > the Web Service's specification.  I've started accepting the value of
> > having my business code do business validations as well (namely in
> > cases where I want to use it from other interfaces), but it just seems
> > too natural, logically, for the XML parsing layer to do it.
> > Otherwise, you're throwing away much of the information you've
> > carefully specified (in a handwritten, authoritative, contract WSDL,
> > at least).
> >
> > I'd be happy to take this discussion somewhere else, since it's really
> > not specific to Axis, if you'd like and if you have time to
> > participate in it.  Thanks.
> >
> > Doug
> >
> > On 7/7/06, Anne Thomas Manes < [EMAIL PROTECTED]> wrote:
> > > Axis makes no attempt to validate messages. (It's very expensive
> > > process that would significantly degrade performance). A databinding
> > > system will catch many validation issues, but it also does not do true
> > > validation. If you pass in elements that it doesn't expect, it will
> > > reject the request. But as long as the message matches what the
> > > databinding system can deal with, it will pass.
> > >
> > > If you want to validate the message, then use a handler or
> > > intermediary to do so.
> > >
> > > Anne
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to