Content-Type: multipart/alternative; boundary="_000_C5ACA287090848EF8CB500EC19FAD8DArackspacecom_" --_000_C5ACA287090848EF8CB500EC19FAD8DArackspacecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Okay, I figured it out. I was using an app that uses a pool of Validators.= You get the error when you reuse the Validator. The following code illustrates it. I'm attaching the schema and instance d= oc I used to test. The relevant part of the code is this: v.validate(new StreamSource(instance)); v.reset(); v.validate(new StreamSource(instance)); The first validate works as expected. The second validate throws the exce= ption: net.sf.saxon.trans.XPathException: Cannot use schema-validated input docume= nts when the query/stylesheet is not schema-aware at com.saxonica.jaxp.ValidatorImpl.validate(ValidatorImpl.java:72) at javax.xml.validation.Validator.validate(Validator.java:127) at com.rackspace.saxon.Test.main(Test.java:30) Caused by: net.sf.saxon.trans.XPathException: Cannot use schema-validated i= nput documents when the query/stylesheet is not schema-aware at net.sf.saxon.event.Sender.makeValidator(Sender.java:470) at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:375) at net.sf.saxon.event.Sender.send(Sender.java:178) at com.saxonica.jaxp.ValidatorImpl.validate(ValidatorImpl.java:65) ... 2 more BTW, would be nice if we could pool Validators and ValidatorHandlers. Xerc= es performs significantly faster when these resources are pooled, so I've g= otten into the habit of pooling them. The fact that Saxon doesn't support p= ooling (I've had issues pooling ValidatorHandlers as well) means I have to = treat Saxon as an edge case -- not that big of a deal -- but would be nice = if Saxon could work as a drop in replacement for Xerces with minimal code c= hanges. Thanks, -jOrGe W. On Jun 25, 2012, at 4:09 AM, Michael Kay wrote: >> I haven't seen that error before, but it looks like you are passing > the validated input to a non-schema-aware transform or xquery. > > That's what the code thinks when it produces this message, but I think > from the evidence that it's wrong. Somehow it has been misled into > thinking that the validation is invoked during query or XSLT processing > when that isn't the case. I haven't been able to determine what > conditions cause this. > > Michael Kay > Saxonica > > -------------------------------------------------------------------------= ----- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > saxon-help mailing list archived at http://saxon.markmail.org/ > saxon-help@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/saxon-help --_000_C5ACA287090848EF8CB500EC19FAD8DArackspacecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1C6F508766D55942876CD9D8850426C1@RACKSPACE.CORP> Content-Transfer-Encoding: quoted-printable
Okay, I figured it out.  I was using an app t= hat uses a pool of Validators.  You get the error when you reuse the V= alidator.

The following code illustrates it.  I'm attaching the schema and insta= nce doc I used to test.

 
 


The relevant part of the code is this:

 v.validate(new StreamSource(instance));
 v.reset();
 v.validate(new StreamSource(instance));

The first validate works as expected.   The second validate throw= s the exception:

net.sf.saxon.trans.XPathException: Cannot use schema-validated input docume= nts when the query/stylesheet is not schema-aware
        at com.saxonica.jaxp.ValidatorIm= pl.validate(ValidatorImpl.java:72)
        at javax.xml.validation.Validato= r.validate(Validator.java:127)
        at com.rackspace.saxon.Test.main= (Test.java:30)
Caused by: net.sf.saxon.trans.XPathException: Cannot use schema-validated i= nput documents when the query/stylesheet is not schema-aware
        at net.sf.saxon.event.Sender.mak= eValidator(Sender.java:470)
        at net.sf.saxon.event.Sender.sen= dSAXSource(Sender.java:375)
        at net.sf.saxon.event.Sender.sen= d(Sender.java:178)
        at com.saxonica.jaxp.ValidatorIm= pl.validate(ValidatorImpl.java:65)
        ... 2 more

BTW, would be nice if we could pool Validators and ValidatorHandlers. = Xerces performs significantly faster when these resources are pooled, so I= 've gotten into the habit of pooling them. The fact that Saxon doesn't supp= ort pooling (I've had issues pooling ValidatorHandlers as well) means I have to treat Saxon as an edge case -- = not that big of a deal -- but would be nice if Saxon could work as a drop i= n replacement for Xerces with minimal code changes.

Thanks,

-jOrGe W.

On Jun 25, 2012, at 4:09 AM, Michael Kay wrote:

>> I haven't seen that error before, but it looks like you are passin= g
> the validated input to a non-schema-aware transform or xquery.
>
> That's what the code thinks when it produces this message, but I think=
> from the evidence that it's wrong. Somehow it has been misled into > thinking that the validation is invoked during query or XSLT processin= g
> when that isn't the case. I haven't been able to determine what
> conditions cause this.
>
> Michael Kay
> Saxonica
>
> ----------------------------------------------------------------------= --------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussi= ons
> will include endpoint security, mobile security and the latest in malw= are
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> saxon-help@lists.sourceforge.net
> ht= tps://lists.sourceforge.net/lists/listinfo/saxon-help

--_000_C5ACA287090848EF8CB500EC19FAD8DArackspacecom_--