[xsd-users] Re: Support for redefine

[Boris Kolpackov]

Hi David,

Moss, David R (SELEX Comms) (UK Christchurch) <david.r.moss at selex-comm.com> writes:

> Are there any plans to support redefine?

No there are no plans to support redefine, mainly for the following
three reasons:

1. It is not widely used

2. Many believe it is a mis-feature

3. It is not clear what the C++ mapping would be


> I'm looking for a way to extend a type in such a way that the element
> name will remain the same, since my code expects an operation to exist
> with that name; Services() in the case of the attached files.

You can do this with xsi:type, though it is not exactly equivalent to
using redefine.

Another, somewhat less elegant but simpler, alternative would be to
add the CallBack element as optional to the original Service_t. This
is conceptually equivalent to redefine since the original schema will
need to "see" the redefine in order to be able to use it (i.e., there
is no "dynamic redefine", as there is with polymorphism). I think
the main idea of redefine is to be able change the schema that you
cannot physically change.


> In the generated code, I guess the issue would be 'hiding' the first
> class definition when a redefinition is encountered; the standard states
> that the extension would apply to all schema components that make use of
> Services_t.

It cannot be just hidden since only the schemas (and generated code)
that "saw" the redefined type will be able to use it.


> I may be able to do something else using the generated type
> customisation approach to insert a function into a services object
> hierarchy (in conjunction with substitution groups) which my code would
> then use but I think this may cause other issues (I need to investigate
> this further!).

Even when using substitution groups, you get the same Service()
function in TestUserConfig. The only "visible" difference between
using substitution groups, xsi:type, and redefine/optional element
is what the XML instance is going to look like and how you access
the data. Here is the summary:


1. Substitution groups: instance have different element names for
   base and derived types. Access is polymorphic (can use dynamic_cast
   to distinguish between base and derived).

2. xsi:type: instance have the same element name for base and derived
   but will need xsi:type attribute for derive. Access is polymorphic
   (can use dynamic_cast to distinguish between base and derived).

3. Optional element: instance have the same element name. To get to the
   "extension" (CallBack) you simply need to check for presence.


hth,
-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/20070202/4849be60/attachment.pgp