Hi Simon, thanks for your thoughts. My comment are below. On 23 May, 14:12, [EMAIL PROTECTED] wrote: > Graham > > I was just thinking about this part of your issue... > > snip> 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? >
Doh! That would work. I got hung up on trying to match the existing contacts schema so I didn't consider that. > > 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. > I think there are probably three classes of transformation: 1. Default SDO serialization (primitives as attributes, complex types as elements). 2. Serialization following an XML schema whose model is logically equivalent to the SDO model (this is what I was trying to do with the contact example (e.g. primitives as elements)). 3. Transformation where the SDO model (types an hierarchy) are not preserved (e.g. remove properties, add properties, change types). Class 1 we should, and do, get for free, although I've not tried this without a schema (do the APIs support this?). Class 2 is what I think should be enabled in SDO as it makes sense to follow a schema during serialization if there is one. Class 3 is where I think people need to write some code :-) . > Regards > > Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
