Glad to hear it worked for you. If you want to support more than an atomic type there is one more solution, not exactly very simple but higher level that playing with the insides of the validator. The solution is to implement a Stax XMLStreamReader over the data you want to validate (be it an entire document or only a subtree - in this case you need the Type of the starting point), and wrap org.apache.xmlbeans.impl.ValidatingXMLStreamReader over it.
On top of validation, ValidatingInfoXMLStreamReader a subclass of ValidatingXMLStreamReader provides Post Schema Validation Info PSVI. Cezar > -----Original Message----- > From: Vance Vagell [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 10, 2007 8:31 AM > To: [email protected] > Subject: RE: Validating a value against a SchemaType object > > Hi all, > > I wanted to share the solution to my earlier question about how to > validate a single String value against a given SchemaType instance (in > isolation, not part of a complete document). Thanks to advice from both > Jacob Danner and Cezar, this is how to do it: > > ValidatorUtil.validateSimpleType(schemaType, value, collection, null); > > This of course only works for simple SchemaTypes, but this meets 80%+ of > the needs of our project, so I'm very grateful. > > Thanks for the help, > Vance > > > > > > > > I just dropped this into my project, and it's validating those > > atomic types like a charm. This should meet the needs of our > > project for this iteration, I can always come back to this if we > > need stricter validation in the future. > > > > > > Thanks so much for the help, > > > Vance > > > > > > > -------- Original Message -------- > > > > Subject: Re: Validating a value against a SchemaType object > > > > From: "Jacob Danner" <[EMAIL PROTECTED]> > > > > Date: Tue, May 08, 2007 3:24 pm > > > > To: "Vance Vagell" <[EMAIL PROTECTED]> > > > > > > > > for #2, did Cezar's advice not work? > > > > validateAtomicType(ScemaType, String, Event) ? > > > > -Jacobd > > > > > > > > On 5/8/07, Vance Vagell <[EMAIL PROTECTED]> wrote: > > > > > Hi Jacob, > > > > > > > > > > Thanks for taking the time to help out. Unfortunately, the XSD is > > > > user-provided, meaning that it is a full-fledged schema that we have > > > > no control over. We display fields that match what the schema > > > > requires (and we have this part working great using XmlBeans), but > > > > as we've been discussing, we're having issues validating individual > > > > user-entered values. > > > > > > > > > > You noted two approaches in your response: > > > > > > > > > > 1) Create a mock XML element (I assume > > VehicleTypeValidateElement is > > > > basically an XmlObject in your example) out of some XML created > > > > on-the-fly that includes the value to be validated. > > > > > > > > > > * I've tried this, first creating an XmlObject and then using > > > > xmlObject.changeType(SchemaType) before calling validate(), but I > > > > always get a "Invalid Type" error. My May 3rd post to this mailer > > > > has a lot of detail around my investigations into this, but I > > > > basically ran into a roadblock and couldn't resolve the "Invalid > > > > Type" error. > > > > > > > > > > 2) Use XmlBeans classes like XmlInt to validate atomic types. > > > > > > > > > > If this is possible, it could be a great workaround until we can > > (if > > > > ever) get #1 to work. However, I just took a look at the Javadocs > > > > for XmlInt and I don't see how we can use this. Here are the > > > > problems: > > > > > > > > > > - How can we go from the SchemaType object (which we parsed from > > the > > > > arbitrary user-provided XSD), to one of these objects (XmlInt, > > > > XmlString, etc.)? > > > > > > > > > > - Once we have an XmlInt, for example, how can we use that for > > > > validation? It seems that each of these classes has its own "set" > > > > method with a unique name; XmlInt has setIntValue() for example. > > > > The generic set() is deprecated, so even if we knew which of these > > > > classes to use, I'm not sure how we'd know which set-method to use. > > > > > > > > > > If you could enlighten me on how to validate a value against an > > > > atomic type, given the SchemaType we have, that would be a great > > > > step in the right direction. We could always come back and look at > > > > constraints in future releases of our project. > > > > > > > > > > Thanks so much, > > > > > Vance > > > > > > > > > > ----------------------------------------------- > > > > > Have you tried using simpleTypes in your XSD for these values. > > > > > ie > > > > > <xs:simpleType name="vehType"> > > > > > <xs:restriction base="xs:token"> <!-- like a string but > > stricter --> > > > > > <xs:enumeration value="car"/> > > > > > <xs:enumeration value="truck"/> > > > > > </xs:restriction> > > > > > </xs:simpleType> > > > > > > > > > > You could then refer to this type in various places in the schema > > > > <xs:complexType name="vehicle"> > > > > > <xs:sequence> > > > > > <xs:element name="typeOfVehicle" type="tns:vehType"/> > > > > > ... > > > > > <xs:element name="VehicleTypeValidateElement" > type="tns:vehType"/> > > > > And when you got the user input you would be able to do something > > > > like: > > > > > VehicleTypeValidateElement v = > > > > > > VehicleTypeValidateElement.Factory.parse("<VehicleTypeValidateElement>"+ us > erInput+"</VehicleTypeValidateElement>"); > > > > > and then ... > > > > > v.validate() > > > > > or what not. > > > > > > > > > > There are several ways to represent the types you could use for > > > > validation in your xsd. I find myself going back to: > > > > > http://www.xfront.com/GlobalVersusLocal.html when the types I want > > > > are not POJOs as I want to access them. > > > > > > > > > > As far as simple atomic types, are you having problems using > > > > XmlInt.setValue, etc? > > > > > > > > > > Thanks, > > > > > -Jacob Danner > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
