This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Assuming that xml:lang is an inheritable attribute, it seems to me that in this instance: <p xml:lang="en"> <q xml:lang="de"> <r xml:lang="jp"/> </q> </p> element q has in its [inheritable attributes] the value {xml:lang="en"}, and element r has the value {@xml:lang="de"}. Specifically, an attribute is excluded from [inheritable attributes] if it is masked by a nearer inherited attribute, but not if it is masked by a real attribute on the element itself. This seems unhelpful.
It seems that the WG was aware of this when it wrote rule 1.1.3 of 3.12.4: 1.1.3 E's [inherited attributes] which do not have the same expanded names as any of E's [attributes]. It still seems an odd way of defining the property; do we really envisage applications which want to know about the inherited attributes even if they are masked by local attributes? This rule also reveals an apparent intent by the WG that inherited attributes should be available for use in Conditional Type Assignment but not in assertions or in so-called identity constraints. Again this seems curious: why the asymmetry? How do we see this moving forward in new versions of XPath and XDM? I would have expected new versions of XDM to expose inherited attributes just like ordinary attributes (the same way defaulted attributes are exposed today). It seems clumsy to suggest that they will sometimes be exposed and sometimes not.
(In reply to comment #1) > This rule also reveals an apparent intent by the WG that inherited attributes > should be available for use in Conditional Type Assignment but not in > assertions or in so-called identity constraints. Again this seems curious: why > the asymmetry? I don't know why the WG defined the nature of inherited attributes as such (i.e they're available in Conditional Type Assignment but not in assertions). I'm curious to know the answer. If we look at assertions spec at, http://www.w3.org/TR/xmlschema11-1/#assertion-validation (section "3.13.4.1 Assertion Satisfied" -> 1.3) it says: "It is a consequence of this construction that attempts to refer, in an assertion, to the siblings or ancestors of E, or to any part of the input document outside of E itself, will be unsuccessful. Such attempted references are not in themselves errors, but the data model instance used to evaluate them does not include any representation of any parts of the document outside of E, so they cannot be referred to." <1> Since inheritable attributes are (lexically?) outside of the element "E" here <1>, therefore they are not available in an XDM tree on which assertions operate. Personally speaking, I find the assertions spec here OK. I would imagine that, users would'nt appreciate (I too find this pretty hard to envisage) to think about attributes outside of the (lexical) real XDM tree of "E" (ref, <1>). This make the schema language a little simpler, but it does satisfy large classes of assertions use-cases. Though, I find inheritable attributes available to CTA XPath evaluations to be OK.
See also bug #11061 on XDM, where I discuss the difficulties that inherited attributes could cause for static type checking in XPath. I can't help feeling in the light of these problems that it would have been better to define inherited attributes on the recipient element - "element P has an @xml:lang attribute whose default value is obtained by inheritance from ancestors". I seem to remember suggesting that at the time, I can't remember what the objection was.
The WG reported this bug as WORKSFORME on 2010-10-22. 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.