Hi Simon, thanks for your thoughts. My comment are below.
On 23 May, 14:12, simonsl... googlemail.com 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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
|
