I was just thinking about this part of your issue...
> I wrote an XML schema to match the schema used by the relational DAS
> (i.e. using the urn:app_namespace, and all primitives were strings).
> This got me nearly all the way there, but then I hit the main snag
> which I hadn't foreseen. The XML which was produced did not follow
> that of the XML schema. It was basically using the default SDO
> serialization, where all primitives are attributes (the schema defined
> them as elements). This meant that on the client side the result came
> back as empty (did not deserialize properly).
How about writing your schema so that it matches the default
serialization of SDO?
> I think what is happening is the SDO's type still ties back to the
> Relational DAS, rather than the XML, during serialization. The
> equivalent XML type has some additional information which enables it
> to be serialized according to the XML schema. Because the SDO type is
> the relational one, this information is not available so the default
> XML serialization rules are used.
This tricky issue you raise here is what the technology specifc schema
is going to look like. In your situation what you did is hand generate
it. In fact what you did is introduce a transformation based on how
you though the output XML should look. There are many ways that XML
schema can be constructed to represent, in this case, relational
schema. To cater for this variability we would have to introduce some
sort of transformation step to ensure that the SDO model can be
converted to the required schema and ensure that that it is output in
that form. ALternatively we could instigate a default transformation
that determines how relational models will be represented in XML. I
guess the output you see now is the default rule.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at