Dear Anaud,

It appears that I have not fully understood the castor validation 
mechanism and although your responses have been very welcome, I require 
a bit more explanation in order to fully comprehend the implications of 
both the validation property settings within the castor.properties file. 
Could you (or keith?) please help me out, so that I understand this 
properly?

I was of the (perhaps mistaken) understanding that by having the property:
org.exolab.castor.marshalling.validation=true within the 
castor.properties file
that castor would do all of the neccessary validation on any xml 
documents that were being deserialised, and that the relevant 
information to do this was derived from the class descriptor for the 
particular class we were attempting to deserialise.

However, I am wondering whether your last email implies that we also 
need to set;
org.exolab.castor.parser.validation=true
to check for things such as;
(*) boolean attributes containing acceptable values
(*) choices of mandatory elements actually containing an entry
(*) required attributes containing values.
(*) prohibited attributes not containing values.

if this is the case, will the parser validation do "all" of the 
validation for us, that is, would it be redundant to have both 
org.exolab.castor.parser.validation=true and 
org.exolab.castor.marshalling.validation=true because some validation 
would take place in two places?

my colleagues here are concerned about the overhead of xerces validation.


any help you can give me on this topic will be greatly appreciated.

best regards,

dave young.



rnaud Blandin wrote:
> Hi Gary,
> 
> In Castor we can see 2 different validations:
>       - the validation of an object model during (un)marshalling
>       - the validation of the xml document towards its grammar during the parsing
> 
> 1) The validation of the object model occurs when you provide an object model
> and a set
> of descriptors that defined some "data constraints" on this object model.
> Typically when using the source code generator, you might want to use this
> validation.
> It is a real alternative for validating data and structure of an object model
> defined
> by an XML Schema.
> 
> 2) When parsing an xml document in Castor, you can decide to validate it towards
> a grammar
> (and in this case you don't have any object model, just an xml document and its
> grammar).
> Ypu can do it by setting the relevant property in the parser you use.
> Castor can set it for you, if you set it in the property file of Castor.
> This has nothing to with unmarshaller.setValidation (that is NOT a static
> method).
> 
> Hope to help you understanding the validation process in Castor,
> 
> Arnaud
> 

----<snip>----
>>
>>
>>Hi Dave,
>>
>>Gary was right, you can validate your xml using Xerces and putting the
>>validation and namespace properties to true.
>>However you were rigth too, there was a bug in Castor validation :+(.
>>I've committed some code in the CVS to correct it.
>>
>>Let me know if it is fine for you,
>>
>>Arnaud
>>
>>
>>>-----Original Message-----
>>>From: dave young [mailto:[EMAIL PROTECTED]]
>>>Sent: Wednesday, August 15, 2001 5:51 AM
>>>To: [EMAIL PROTECTED]
>>>Subject: Re: [castor-dev] unmarshalling choices, expecting validation
>>>errors but not getting them
>>>
>>>
>>>Gary,
>>>
>>>Thanks for your response and suggestion. Unfortunately my situation is
>>>unchanged.
>>>
>>>I'm pretty confident that I am using the latest version of castor (well,
>>>i downloaded it at approximately 5:00am tuesday 14/8/2001 GMT)
>>>I compared the webcvs versions of the two files you mention and they are
>>>identical to those that i am already using. :-)
>>>
>>>I am still having the problem that within my environment, castor is not
>>>detecting when a choice of mandatory elements contains no content
>>>whatsoever. :-(
>>>
>>>Once deserialised, if i interrogate the object directly, both choices
>>>(getMilitary() and getCivilian()) return null, but the isValid() method
>>>returns true.
>>>
>>>Can anybody confirm to me that this should definitely be fixed in the
>>>current cvs source snapshot of castor? If so, I must be doing something
>>>wrong somewhere
>>>
>>>regards,
>>>
>>>dave young.
>>>
>>>ps: after carrying out tests, we have realized that the bit of extra
>>>source code i attached last time actually causes other problems
>>>(noticeably when you have a choice full of optional elements and no
>>>content for the choice is supplied).
>>>
>>>pps: attached again for completeness is the xml schema and the xml
>>>instance for which i would expect errors to occur:
>>>
>>>-------------< start schema >---------------------
>>><xsd:element name="SoldierOrCivilian">
>>><xsd:complexType>
>>>   <xsd:choice>
>>>        <xsd:element name="Military" type="t_Military"/>
>>>        <xsd:element name="Civilian" type="t_Civilian"/>
>>>   </xsd:choice>
>>></xsd:complexType>
>>></xsd:element>
>>>
>>><xsd:complexType name="t_Military">
>>>   <xsd:sequence>
>>>        <xsd:element name="Rank" type="xsd:string"/>
>>>        <xsd:element name="Unit" type="xsd:string"/>
>>>   </xsd:sequence>
>>></xsd:complexType>
>>>
>>>
>>><xsd:complexType name="t_Civilian">
>>>   <xsd:sequence>
>>>        <xsd:element name="Name" type="xsd:string"/>
>>>        <xsd:element name="Company" type="xsd:string"/>
>>>   </xsd:sequence>
>>></xsd:complexType>
>>>----------------------<e nd schema >-----------------------
>>>
>>>xml instance:
>>><SoldierOrCivilian>
>>></SoldierOrCivilian>
>>>
>>>
>>>
>>>
>>>>Dave,
>>>>
>>>>I had the same problem. Its because the Unmarshaller in 0.9.3 did
>>>>
>>>not have an
>>>
>>>>ErrorHandler set.
>>>>
>>>>Arnaud has fixed the problem in CVS around the 1st August.
>>>>
>>>>Grab the latest Unmarshaller.java and UnmarshalHandler.java from
>>>>
>>>CVS and rebuild
>>>
>>>>the JAR
>>>>
>>>>Regards,
>>>>
>>>>Gary


------< legalese deleted >-------
> 
> 
> 
> 

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to