RE: Default and Fixed Values of attributes

 
1)   In 2.1 it says that the stuff in 2.1.3 must be true IF B is in the same
target namespace as R. That is interesting. What if the schema that defines
R is imported in the schema that defines B? 
 
No, it's not saying that B must be in the same namespace as R: it's saying
that if B has an attribute with the same expanded name as an attribute in R,
then certain conditions must hold. 
 
2)   I would be obliged to receive your reaction on the other questions in
my message, viz:
*         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).  
 
In section 3.2.3 is the rule: 
 
 
1 default and fixed must not both be present.
2 If default and use are both present, use must have the
<http://www.w3.org/TR/xmlschema-1/#key-vv> .actual value. optional. 
 
 
I wouldn't expect to see a rule that the presence of a fixed or default
value changes the {required} value, and I'm pretty sure there is no such
rule.
 
 
*         Can you 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.
 
Others would be better qualified than me to comment on the rationale. It
does seem to me that extension and restriction are rather different
operations. The main difficulty I have in practice is that if one element A
allows three children P, Q, and R, and another element B allows only P and
Q, then it's not clear whether B should be derived from A by restriction, or
A derived from B by extension. Which option you choose doesn't affect the
result of validation, but it can have a significant impact when you start
writing schema-aware XSLT and XQuery. (Of course, this is an old dilemma in
object-oriented design.)
 
Michael Kay
http://www.saxonica.com/