On 05/12/06, Simon Laws <[EMAIL PROTECTED]> wrote:
On 12/5/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> On 05/12/06, Simon Laws <[EMAIL PROTECTED]> wrote:
> >
> > Hi Pete
> >
> > Some comments in line...
> >
> > On 12/5/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > >
> > > A number of SDO issues have come up over the past week regarding
> > sequenced
> > > data objects. I think the current implementation is incorrect in a
> > number
> > > of
> > > ways.
> > >
> > > For a sequenced data object you can use the "sequence api" to
get/set
> > the
> > > values of properties in the sequence. You can also use the standard
> > setXXX
> > > methods on DataObject to set the properties. If you do this,
however,
> > then
> > > the values are not added to the sequence. This is incorrect.
> >
> >
> > Agreed, sequence should just be a view on the DO so data shouldn't
> appear
> > in
> > one and not the other.
> >
> > The sequence is a sequence of 'elements' in XML terms. Properties that
> are
> > > defined as attributes should be set using the normal setXXX methods
> and
> > > should NOT be added to the sequence. They will not be returned when
> > using
> > > the get methods from the sequence api.
> >
> >
> > I'm not sure how you define or identify a property as an attribute,
> other
> > then by reading in a schema, but it sounds a little complicated to ask
> the
> > user to make the decision.
>
>
> If the user decides to define Types and Properties programmatically then
> he
> is the only one that can make the decision as to how it should be
> serialized. This control is, I believe, added in to the Java and C++
spec
> APIs now. If the Types/Properties are defined using a schema then the
> XSDHelper will do this work for you.
>
> Properties that are defined to an open type when loading a schemaless
xml
> > > document should have PropertyInformation attached to indicate
whether
> > the
> > > property is an attribute or element.
> >
> >
> > Agreed. Regardless of whether the type is open it can still have
> elements
> > and attributes in XML
> >
> > Properties that are not defined via DataFactory::addPropertyToType
> should
> > be
> > > treated as elements and added to the sequence.
> >
> >
> > I don't understand this.
>
>
> This is properties defined dynamically when setting a value on an Open
> type.
>
> The CopyHelper will have to copy the sequenced SDO by using the sequence
> API
> > > and then using the DataObject getter/setted methods to copy
properties
> > > that
> > > were xml attributes.
> >
> >
> > Can we remove this difference between sequences and DOs
>
>
> I don't understand this.
>
> Any other thoughts?
> > >
> > > --
> > > Pete
> > >
> > >
> > IMHO sequences feel a little strange in the way that they are
> articulated
> > in
> > the SDO API as it stands. It seems that the primary motivation for SDO
> is
> > unordered access to data based on type or property name. Sequenced
> access
> > stands out as an add on extra. From a users perspective I'd like a
> simpler
> > approach. For example, in PHP I might access a named property as:
> >
> > // using object property accessor
> > $value = $myDO->prop1;
> >
> > or
> >
> > // using an associative array accessor
> > $value = $myDO['prop1'];
> >
> > The PHP approach also allows iteration over objects so I could do:
> >
> > foreach ( $myDO as $propName => $propValue ) {
> > echo $propName . " = " . $propValue;
> > }
> >
> > The order here is naturally the order in which types are defined not
the
> > order in which data is added. So far so good. SDO fits in well.
> >
> > If though there is some underlying order of the property values then
in
> > SDO
> > currently I would do something like
> >
> > $sequence = $myDO->getSequence();
> >
> > an then go ahead and use the $sequence as though it were the DO.
> >
> > This is not so bad but I think it would be cleaner if the DO knew
> whether
> > it
> > was sequenced or not (It does already) and managed values through it's
> > interface based on this knowledge. I wouldn't then be faced with
having
> to
> > decide where to add a piece of data, sequence or DO, based on whether
I
> > though it might end up as an attribute or not when the time comes to
> > serialize the DO. I would expect the DO to sort this out for me.
> >
> > Just my 2c
> >
> > Simon
> >
> >
> The sequence api is necessary for ordering of settings. I think I AM
> proposing that the SDO code does manage the values so if you do
> myDO->setInt("fred", 41); the SDO code delegates this to the sequence
api
> if myDO is sequenced.
>
> --
> Pete
>
> Ah, now that sounds like a step in the right direction. Is there still
an
implication though that sometimes the user will have to make a choice, i.e
.
in the case of attributes and elements?
Simon
The user would have to make a choice only if they wanted to alter the
default serialization behaviour as defined in the spec. I need to chack the
latest wording but I think the defaults are attribute for a single
valued simple type, element for many-valued, dataobjects etc.
Cheers,
--
Pete
