Vance,
The key is to get an XmlObject whose Schema type (as returned by
XmlObject.schemaType()) is the Schema type that you want to validate
against. There are multiple ways to get that, but in your case what may
be applicable and don't think was mentioned thus far is
SchemaTypeLoader.newInstance().
So if 'SchemaTypeLoader stl' is what you use to load your types and
'SchemaType st' is the type that you want to validate against (which you
must of course know beforehand since you don't have an element
declaration), then
XmlObject obj = stl.newInstance(st, null);
will create an empty XmlObject of that type and
((XmlAnySimpleType) obj).setStringValue(value);
will set the content of that object to 'value' (assuming like you said
that it is a simple Schema type, which you can also verify).
Now you should be able to do obj.validate()
Radu
On Tue, 2007-05-08 at 12:05 -0700, Vance Vagell 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>"+userInput+"</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]
