[sdo] [SDO-45]: Needs different SDO types to map to XSDbase64Binary and hexBinary

[Radu Preotiuc-Pietro <radup@bea.com>]

Frank Budinsky [25/Apr/07 07:35 PM] 
In Tuscany we have fixed this problem by introducing a new type
{commonj.sdo}Base64Bytes. The alternative would seem to be keeping some
implementation specific information behind the scenes that identifies
the "real type" - base64Binary or hexBinary.


Blaise Doughan [26/Apr/07 04:19 PM] 
My concern with the Tuscany "fix" is that by adding a new type in the
"commonj.sdo" namespace this would lead customers into believing that
this is an official spec defined type when in fact it is not (atleast
not yet). In our (Oracle) SDO implementation we use the namespace
"oracle.sdo" for our own extensions.

Having seperate SDO types for both hexBinary and base64Binary makes
sense if SDO is solely an XML representation (which I do not believe it
is). Since hex or base64 are strictly XML representation issues, perhaps
there should be something in the "commonj.sdo/xml" namespace that can be
used to qualify properties that are of type Bytes?


Andy Grove [26/Apr/07 04:26 PM] 
This does sound similar to the commonj.sdo/xml#xmlElement property which
is used to control whether primitive properties are serialized to XML as
an attribute or an element, so I think Blaise's suggestion makes sense.


Fuhwei Lwo [07/Jun/07 06:22 PM] 
This many XSD to one SDO type mapping happens to SDO URI type too.
Currently, both xsd:anyURI and xsd:QName types are mapped to SDO URI
type. Please refer to SDO spec 2.1 page 93.



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.