Handling this in the same way as we handled base64Binary sounds right to me. We didn't override createFromString and convertToString, however. We simply mapped internally to the EMF base64Binary type and let EMF handle it in its default way.
Note that the code to make this work is in AttributeImpl.getType() and in SDOXSDEcoreBuilder.getBuiltInEClassifier(). Thanks, Frank. Fuhwei Lwo <[EMAIL PROTECTED]> wrote on 06/04/2007 04:23:15 PM: > I believe we have a bug in loading/saviing xsd:QName property value. > Based on SDO 2.1 spec section 9.4.1, proper conversion should take > place. Unfortunately, Tuscany SDO is not doing any conversion today. > If no one objects, I will open a JIRA. > > When I started to look into possible solution for this problem, I > discovered both xsd:anyURI and xsd:QName are mapped to SDO URI type. > This is similar to JIRA 1223 Frank has fixed for xsd:base64Binary > and xsd:hexBinary. I think we can copy what 1223 has done by > internally mapping xsd:QName to SDO QName type then in the > SDOXMLResourceImpl$SDOXMLHelperImpl, override createFromString and > convertToString for deserialization and serialization respectively. > > Let me know if this proposed solution makes sense. > > Fuhwei --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
