[xsd-users] plans for xsd 1.4.0

Boris Kolpackov boris at codesynthesis.com
Tue Sep 20 09:57:26 EDT 2005


Good day,

We are planning to make a backwards-incompatible change in the C++/Tree
mapping for xsd 1.4.0. The change is going to affect the interface
that is used to access optional (cardinality 0..1) elements/attributes.
The following examples will illustrate the difference.

Suppose we have the following XML Schema fragment:


<complexType name="Foo">

  ...

</complexType>

<complexType name="Bar">
  <choice>
    <element name="foo" type="Foo"/>
  </choice>
</complexType>


In the current version one would access element 'foo' like this:


Bar& bar = ...

if (bar.foo.present ())  // test
{
  Foo& foo = bar.foo (); // get

  bar.foo (Foo (...));   // set

  bar.foo.reset ();      // reset
}


After the change the same example would look like this:


Bar& bar = ...

if (bar.foo ())           // test
{
  Foo& foo = *bar.foo (); // get

  bar.foo (Foo (...));    // set

  bar.foo (0);            // reset
}

Or alternatively like this:


if (Foo* foo = bar.foo ()) // test & get
{
  ...
}


Due to inlining the above two cases should be equivalent performance-wise.

Here is the motivation for this change:

 1. The new interface uses 'iterator' concept which is also used in the
    access API for sequences (cardinality 0..many). In other words, with
    this change the way one accesses optional elements and sequences of
    elements will be conceptually equivalent.

 2. The current interface's implementation is based on functors. This model
    is somewhat unconventional and proved to be hard to explain. For example,
    when one looks at the generated code it sees something like

    struct Bar
    {
      optional<Foo> foo;
    };

 3. The use of functors makes some useful features inaccessible. For example,
    function overloading in derived classes (via using-declaration) and
    virtual functions that may be needed in case of a polymorphic schema.


Other features that we plan to implement for 1.4.0 are refType attribute
for IDREF and IDREFS and support for the xsd:list construct.

Your feedback on the proposed changes/new features is always appreciated.


-boris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050920/a903a368/attachment.pgp


More information about the xsd-users mailing list