Default and Fixed Values of attributes

Ladies and gentlemen,
 
I am struggling with Default and Fixed Values for attributes, and I need
your advice.
 
Assume:
*	complexType A with attribute 'a'
*	complexType B is typed with A and the inherited attribute 'a' is
restricted by means of a default or fixed value "value1"
*	complexType C is typed with B and the inherited attribute 'a'
has the inherited default or fixed value "value1"
 
Now I want to define an other default or fixed value "value2" for
inherited attribute 'a' of complexType C because that value is, in the
real world, different for this subtype. WRONG!!! When I do that (in
XMLSpy, latest version) that "value2" is kind of "inherited backwards"
to the inherited attribute 'a' of complexType B, but not to A (see
below)
 
I have the same phenomenon when I have:
*	above complexType C
*	element E1 typed with C
*	element E2 typed with C
 
When I do this typing in the restricted mode and then define a default
or fixed value for the inherited attribute 'a' then I see the same
backwards inheritance to B, but not to A. The latter seems to depend
whether or not you already changed something to attribute 'a' of A (e.g.
its use constraint). STRANGE!!!
 
Can you explain to me:
*	whether this is a bug or something meant to be this way
*	if the latter applies: why is it meant this way? The rationale
escapes me.
 
A related question is whether or not the definition of a default or
fixed value should have as a consequence that the use constraint should
become "optional" (for default values) or even should be removed at all
(for fixed values). XMLSpy seems to be internally confused, because I
get an error message that it should be "optional", and when I change it
to "optional" I get the error message that it should be "required"
because the base type says so. So how do I get out of this catch 22, and
what it the right answer I should tell the XMLSpy people in my bug
report? (XMLSpy also removes the simpleType of the defaulted attribute
and then tells you (in Text View only) that that should not have been
done!).
 
Now I have you on the line, can you also explain the rationale for the
split between specialization(typing)_by_extension and
specialization_by_restriction? From a data modelling point of view that
is illogical, because adding an attribute or child element also
constitutes an extra constraint, and besides that it is highly
inconvenient and causes a lot of hassle.
 
I hope that someone of this distinguished guild can help me out!
 
Kind regards,
Hans
 
_______________________
 
Hans Teijgeler
co-modeller of ISO 15926-2
author of ISO 15926-7
visit  <http://www.InfowebML.ws> www.InfowebML.ws
phone: +31-72-509 2005
e-mail: hans.teijgeler@quicknet.nl
_____________________________