Subject:Re: What does this Error mean please Author:(Deleted User) Date:18 Jun 2002 01:54 PM
At 12.18 18/06/2002 -0400, you wrote:
>From: "Martin Roberts"
>
>Recurse: There is not a complete functional mapping between the particles
>
>I get it when I do a restriction of a type and then do not use any of the
>elements but add new ones.
If I understand what you are doing, it's not a legal schema. From the specs:
2.2.1.1 Type Definition Hierarchy
....
[Definition:] A type definition whose declarations or facets are in a
one-to-one relation with those of another specified type definition, with
each in turn restricting the possibilities of the one it corresponds to, is
said to be a restriction. The specific restrictions might include narrowed
ranges or reduced alternatives.
In plain English, a restriction can only repeat the elements or structures
of the base type and change its allowed values (or make an attribute
prohibited).
The "Schema Component Constraint: Particle Valid (Restriction)" paragraph
at 3.9.6 lists how this mapping should be done: if this table seems to
validate the restriction you are defining, please provide us (or the
Xerces-C++ team directly) with a testcase.
>I am doing this as I want to do a substitution of an entirely new type
>without using the xsi:type mechanism.
Subject:Re: What does this Error mean please Author:(Deleted User) Date:19 Jun 2002 11:32 AM
At 04.26 19/06/2002 -0400, you wrote:
>From: "Martin Roberts"
>
>The problem is if the substitution group head element is not empty and you
>do not want the heads structure you are not able to do what I want.
>
>i.e
> type x with element y as content
> type z with element a as content
>
> type x is defined by library outside of my control
>
> If I declare element b of type x and element c of type z
> substitutiongroup b, I can not get it to work.
Yes, you are right; it looks that everything that deals with inheritance in
the XMLSchema specs (derivation by restriction, substitutionGroup,
xsi:type, redefine) doesn't allow what you have in mind. They are defined
to build an inheritance tree, where every instance of a derived type is a
valid instance of the base type: so you cannot remove pieces of the base
class (after all, you couldn't do it in a object-oriented language too...)