[xsd-users] Creating elements in code

[Boris Kolpackov]

Hi Attila,

Attila <atteeela at gmail.com> writes:

> What I was thinking was to have the parsed CS XSD objects as the
> "configuration collection" underneath and then be able to use
> webservices or something to dynamically replace the CS XSD objects.
>
> So if someone sends a command to replace element "foo", then I could just
> parse this element, and then use it to replace the foo element in my
> configuration collection underneath.  Furthermore, will I be able to
> potentially "build up" a "more complete" configuration file (defined by say
> mytoolConfig.xsd) and then write it out to an instance document:
> configsnapshot.xml?

Yes, this would be pretty straightforward as long as both the the complete
configuration file and the fragments that you receive are valid (according
to the schema) XML documents. To give you an example, suppose you have a
third element in your schema that describes the "complete" configuration:

<xs:element name="config">
  <xs:complexType>
    <xs:sequence>
      <xs:element ref="note"/>
      <xs:element ref="foo"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

You can then do the following:

auto_ptr<config> c = config_ ("complete-config.xml");

// Receive a note fragment.
//
auto_ptr<note> n = note_ ("note.xml");

// Replace the note fragment in the config with the one we just received.
//
c->note (*n);


> Also: will the CS XSD parser restrict how many instances I can have of say
> "foo" if my mytoolConfig.xsd says I can only have 1 instance?

If the cardinality of a local element is 1 (e.g., note or foo in the above
config) then the generated interface simply won't allow you to have more
then one instance in the object model. Once you set the new value as in
the last line above, the previous value is gone.

Boris