Hi Thomas,

Xerces2 supports the functionality of preparsing and caching grammars.
Assume all XML instances that your application processes conform to the
same schema. Then instead of loading the schema each time you parse such an
instance, you can preparse and cache this schema (store it in a grammar
pool) that the parser has access to. For more information, you can refer to
the online documentation of Xerces2 [1].

Back to the dynamic validation feature. As I mentioned, whether the root
element has xsi schema location attribute(s) doesn't necessarily indicate
whether the instance can be validated. The Schema spec doesn't require that
a Schema-valid document *has to* have those attributes on the *root*
element. The following 2 samples are both schema-valid, but neither have
such attribute on the root element.

1. As in my early message: xsi:type attributes are used.

> <root xmlns:xsi="..." xmlns:xs="..." xsi:type="xs:anyType>
>   <c1 xsi:type="xs:int"> 123 </c1>
> </root>

2. Schema location attribute(s) on non-root element(s).

<root xmlns:xsi="..." xmlns:xs="..." xsi:type="xs:anyType>
  <c1 xsi:noNamespaceSchemaLocation="myschema.xsd">
    ...
  </c1>
</root>

So the dynamic validation feature in Xerces can't simply depend on the
presence of those attributes on the root element, but it really means
"validate if you can". Better suggestion is always welcome, but I think
this interpretation is more reasonable: at least it doesn't go against the
Schema spec.

And to clarify, even without the dynamic validation feature, if the
declaration/type definition can't be found for the root element, it doesn't
mean the instance is "invalid". Of course, it's not valid either. Its
validity is "unknown". For historical reasons, Xerces reports an error in
this case, but in PSVI, the validity for the root element should be set to
"unknown". (It's current "invalid" in Xerces' PSVI, which is a bug, and
I'll fix it.)

[1] http://xml.apache.org/xerces2-j/faq-grammars.html

Cheers,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]



                                                                                       
                                                
                      Thomas B�rkel                                                    
                                                
                      <[EMAIL PROTECTED]>           To:       "Xerces Dev Mailinglist" 
<[EMAIL PROTECTED]>                        
                                               cc:       Sandy Gao/Toronto/IBM@IBMCA   
                                                
                      10/22/2002 08:58         Subject:  Re: Dynamic Validation for 
XML Schema (was: DO NOT REPLY [Bug 13729])         
                      AM                                                               
                                                
                      Please respond to                                                
                                                
                      xerces-j-dev                                                     
                                                
                                                                                       
                                                
                                                                                       
                                                



HI!

First of all: What is grammar caching/pool?

To us, it looks like this:

We want no error for XMLs that do no need to be validated. Those XMLs have
no schema location. Thus, we have to use dynamic validation on.

We want an error for XMLs that do need to be validated (they have a schema
location attribute), but the schema is not available, even with dynamic
validation on.

This was exactly the behavior before 2.2.0.

Regards,
Thomas

[EMAIL PROTECTED] wrote:
>
> I agree it was a behavior change, but, to me, it's a just a fixed bug:
> Dynamic Validation didn't work for Schema.
>
> Original, this feature depends on whether there is/are xsi schema
location
> attribute(s) on the root element. But this is not appropriate, because:
> 1. With grammar caching, one can put a grammar in the grammar pool, and
> don't have any schema location attribute in the document;
> 2. The following instance without schema location attribute is still
> schema-valid:
>
> <root xmlns:xsi="..." xmlns:xs="..." xsi:type="xs:anyType>
>   <c1 xsi:type="xs:int"> 123 </c1>
> </root>
>
> Anyway, since you are using this feature, what do you think it should
> really mean.
>
> Thanks,
> Sandy Gao
> Software Developer, IBM Canada
> (1-905) 413-3255
> [EMAIL PROTECTED]
>
>
>                       [EMAIL PROTECTED]
>                       rg                       To:
[EMAIL PROTECTED]
>                                                cc:
>                       10/18/2002 04:40         Subject:  DO NOT REPLY
[Bug 13729]  -     name of root node is not being enforced by
>                       AM                        schema
>                       Please respond to
>                       xerces-j-dev
>
>
>
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13729>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13729
>
> name of root node is not being enforced by schema
>
> ------- Additional Comments From [EMAIL PROTECTED]  2002-10-18 08:40
> -------
> Well, at least Xerces 2.2.0 behaves different here than previous
versions.
> We
> found the old behavior much better for our needs. Same for bug #13730.
>
> ---------------------------------------------------------------------
> 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