[C++] SDO sequenced data objects

[Pete Robbins <ro...@googlemail.com>]

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.

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.

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.

Properties that are not defined via DataFactory::addPropertyToType should be
treated as elements and added to the sequence.
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.

Any other thoughts?

-- 
Pete

Re: [C++] SDO sequenced data objects

[Caroline Maynard <ca...@gmail.com>]

On 05/12/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> On 05/12/06, Simon Laws <si...@googlemail.com> wrote:
>

> > 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.


Pete's describing the internal implementation of CopyHelper::copy().  This
isn't stuff that the user would have to do.

I think what you're asking for is that the copy function itself can either
be:
DataObjectPtr copy(DataObjectPtr dataObject);
or
SequencePtr copy(SequencePtr sequence);

and that the created DO together with its Sequence would be the same
regardless of the method signature?

-- 
Caroline

Re: [C++] SDO sequenced data objects

[Pete Robbins <ro...@googlemail.com>]

On 05/12/06, Simon Laws <si...@googlemail.com> wrote:
>
> On 12/5/06, Pete Robbins <ro...@googlemail.com> wrote:
> >
> > On 05/12/06, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > Hi Pete
> > >
> > > Some comments in line...
> > >
> > > On 12/5/06, Pete Robbins <ro...@googlemail.com> 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

Re: [C++] SDO sequenced data objects

[Simon Laws <si...@googlemail.com>]

On 12/5/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> On 05/12/06, Simon Laws <si...@googlemail.com> wrote:
> >
> > Hi Pete
> >
> > Some comments in line...
> >
> > On 12/5/06, Pete Robbins <ro...@googlemail.com> 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

Re: [C++] SDO sequenced data objects

[Pete Robbins <ro...@googlemail.com>]

On 05/12/06, Simon Laws <si...@googlemail.com> wrote:
>
> Hi Pete
>
> Some comments in line...
>
> On 12/5/06, Pete Robbins <ro...@googlemail.com> 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

Re: [C++] SDO sequenced data objects

[Simon Laws <si...@googlemail.com>]

Hi Pete

Some comments in line...

On 12/5/06, Pete Robbins <ro...@googlemail.com> 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.

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.

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

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