[Speaking for myself]

It may depend on what you mean by the question "Then, can X have
this attribute present (an inheritable attribute) in the instance
document, and will this instance be considered valid?"

For concreteness, consider your example, with an inheritable
version of xml:lang, and let's assume that X is in some target
namespace tns.

(1) If you mean "Will the element instance <tns:X
xml:lang="fr">Bonne chance!</tns:X> be valid against the
declaration?", then I think the answer is no.  If we validate the
instance element against the declaration, then a partial list of
the constraints checked will include:

  Schema Validity Assessment (Element), with the declaration
  given as the stipulated element declaration.  Clause 1.1.2
  leads to:

  Element Locally Valid (Element), again with the stipulated
  element declaration.  Here, clause 5.2.1 leads us to:

  Element Locally Valid (Type), with xsd:string as the governing
  type definition.  Here clause 3.1.1 says that the element must
  have no attributes other than xsi:type, xsi:nil,
  xsi:schemaLocation, or xsi:noNamespaceSchemaLocation, so the
  element instance is not valid against its governing type
  definition.

(2) If you mean "Will the element instance <tns:X>Try again
later</tns:X> be valid, even though it has an 'inherited' value
for xml:lang?", then I think the answer is yes.  The validation
log goes along just as before, but when we hit

  Element Locally Valid (Type), with xsd:string as the governing
  type definition.  Here clause 3.1.1 says that the element must
  have no attributes other than xsi:type, xsi:nil,
  xsi:schemaLocation, or xsi:noNamespaceSchemaLocation, and the
  element instance satisfies this clause.  It also satisfies the
  other requirements, so the isntance is valid against type
  xs:string.

And since the element also satisfies the remaining clauses of
Element Locally Valid (Element) and Schema Validity Assessment
(Element), the element instance is valid.

........

Note that the element declaration for X can refer to inherited
attributes in the tests of its type alternatives, even if the
assigned type is simple.  So the element declaration

  <xsd:element name="X" type="xsd:string">
    <xsd:alternative test="@xml:space='default'" type="xsd:anyType"/>
  </xsd:element>

which assigns X either the type xsd:string or the type
xsd:anyType, depending on the inherited value of xml:space.

If users find it confusing that the type of X can depend on
xml:space, but instances of X cannot carry the xml:space
attribute, then it may be better practice to define a complex
type with simple content, extending xsd:string by allowing the
appropriate attributes.

Here's a use case: a document has an outermost element of <product-data> with a version attribute whose value is version="1" or version="2". Deep within the document, element size has two alternative types: if version="1" the type is string with a pattern facet [0-9]+(in|cm); if version="2" the type is a complex type with simple content allowing instances such as <size units="cm">5</size>.

To make this work with conditional type assignment, you make product-data/@version an inherited attribute, and you make the type of the size element have two alternatives, one being a simple type, the other a complex type with simple content. You can refer to @version as an inherited attribute in the test expression of the xs:alternative elements, even though the version attribute can't actually appear on the size element.

Now, it might have been clearer to the reader if the XPath expression had been ../@version rather than ./@version. We're trying to have our cake and eat it here: to disallow context-dependent validation while also allowing it in a limited number of cases where we think it makes sense. There might be better ways we could have done it, but we were trying to compromise between these two objectives and that's what we did.

(In reply to comment #1)

Thanks for the explanation. I think, I am now quite clear about the inheritable attributes concept.

As I wrote in my earlier message, I was under impression, that if an attribute is declared as inheritable, then it may actually be copied (i.e, physically be present) in the descendant elements. But as you wrote, that this interpretation is incorrect. The meaning of simple types, and simple contents won't change by presence of inherited attributes.

Inherited attributes only exist in the context of a particular descendant element (but they cannot be psysically present in the descendant elements, if the descendant element's type is simple). Inherited attribute can be referred in conditional type alternatives, and I think, also in assertions.

So is it right to believe, that inheritable attributes are designed in the spec, to be usable only in conditional type alternatives (CTA), and assertions? Or they can have usage, other than these two facilities (CTA and assertions)?

Regards,
Mukul

(In reply to comment #2)
> Here's a use case: a document has an outermost element of <product-data> with a
> version attribute whose value is version="1" or version="2". Deep within the
> document, element size has two alternative types: if version="1" the type is
> string with a pattern facet [0-9]+(in|cm); if version="2" the type is a complex
> type with simple content allowing instances such as <size units="cm">5</size>.
> 
> To make this work with conditional type assignment, you make
> product-data/@version an inherited attribute, and you make the type of the size
> element have two alternatives, one being a simple type, the other a complex
> type with simple content. You can refer to @version as an inherited attribute
> in the test expression of the xs:alternative elements, even though the version
> attribute can't actually appear on the size element.
> 
> Now, it might have been clearer to the reader if the XPath expression had been
> ../@version rather than ./@version. We're trying to have our cake and eat it
> here: to disallow context-dependent validation while also allowing it in a
> limited number of cases where we think it makes sense. There might be better
> ways we could have done it, but we were trying to compromise between these two
> objectives and that's what we did.

Thanks, Mike for the explanation. It's quite helpful.

Regards,
Mukul 

(In reply to comment #1)
> [Speaking for myself]
> 
> It may depend on what you mean by the question "Then, can X have
> this attribute present (an inheritable attribute) in the instance
> document, and will this instance be considered valid?"

I have another question.

If we have an element declaration like following:

<xs:element name="X">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="Y">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="Z" type="xs:string">
              <xs:alternative test="@a='test'" type="xs:anyType" />
            <xs:element>
          </xs:sequence>
          <xs:attribute name="a" type="xs:integer" inheritable="true" />
        <xs:complexType>
      <xs:element>
    </xs:sequence>
    <xs:attribute name="a" type="xs:string" inheritable="true" />
  </xs:complexType>
</xs:element>

This corresponds to element hierarchy like following:

<X a="test">
  <Y a="1">
   <Z ...>
  <Y>
</X>

The attribute "a" on X, and also "a" on Y are both inheritable. In this case, would the element Z inherit attribute "a" of element Y or of element X? Does the XML Schema 1.1 spec defines a policy, to inherit attributes from the nearest ancestor (i.e, in this case Z inherits attribute "a" from Y and not from X)?

Or, is the usage of inheritable attributes, as in this example, an error?

I would appreciate, if you could pls answer my earlier question as well:

"are inheritable attributes designed only for conditional type alternatives and assertions? or they have other usage as well?"

I would appreciate, if you could please point me to relevant sections of the spec, explaining these points.

Regards,
Mukul

The value of an inherited attribute is taken from the nearest ancestor which provides a value for an attribute of that name.  So in your example, element Z will have an inherited attribute named 'a', with the value 1.

For further discussion, interested readers may wish to consult a recent email exchange on the xmlschema-dev list, beginning with an inquiry from Roger Costello at 

  http://lists.w3.org/Archives/Public/xmlschema-dev/2009Jun/0044.html

and including a summary of the relevant rules in section 3.3.5.6 by Michael Kay at 

  http://lists.w3.org/Archives/Public/xmlschema-dev/2009Jul/0002.html

On your other question, I hesitate to answer.  It's certainly the case that inheritance of attributes was introduced as a way of helping resolve bug 5003, which concerned a requirement to refer to the attribute xml:lang in conditional type assignments and/or assertions.  I don't know of any other constructs in which they will be useful, but I hesitate to make a blanket statement that they have no other uses, because sometimes ingenious people find ways to use things that I would not have predicted.  I think, though, that your characterization is probably correct, because inherited attributes become visible only in the construction of the XDM instance used to evaluate the XPath expressions of assertions and conditional type assignment.  If they are not visible or mentioned elsewhere, it's hard to see how to use them elsewhere.  

Certainly it's safe to say that the WG didn't have any other particular usage of inherited attributes in contexts other than evaluating assertions and type alternatives in mind at the time the construct was developed.  At least, there is no record of it that I can see.  I hope this helps.

The WG has not yet discussed this issue; I am speaking here only for myself.

(In reply to comment #6)
> The value of an inherited attribute is taken from the nearest ancestor which
> provides a value for an attribute of that name.  So in your example, element Z
> will have an inherited attribute named 'a', with the value 1.

Thanks, for a very helpful explanation. I feel, all my doubts at this moment, about inherited attributes, are answered.

From my point of view, you may close this bug request. Or, you may keep this bug open, for official consideration by the WG, and a closure later.

I regard, your answer as an official WG response.

Regards,
Mukul

Thanks for this insightful discussion.  The WG has concluded that we should close this issue since the original poster is now happy.

The WG reported this bug as WONTFIX on 2009-08-03.  We are closing this bug as
requiring no futher work.  If there are issues remaining, you can reopen this
bug and enter a comment to indicate the problem.  Thanks very much for the
feedback.