This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11061 - [XDM 3.0] Support for XSD 1.1 inherited attributes
Summary: [XDM 3.0] Support for XSD 1.1 inherited attributes
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 3.0 (show other bugs)
Version: Proposed Edited Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2010-10-15 08:37 UTC by Michael Kay
Modified: 2010-11-16 16:36 UTC (History)
0 users

See Also:


Description Michael Kay 2010-10-15 08:37:30 UTC
As part of its support for XSD 1.1, XDM rules for creating an instance from a PSVI should recognize the new [inherited attributes] property of an element information item. Attributes present in the property should be converted to XDM attribute nodes in the same way as defaulted attributes, so they are accessible to XPath expressions.

The property arises when an attribute is specified in the schema with inherited="true", which causes it to be visible (rather in the same way as defaulted attributes) on its descendant elements.

The design of XSD 1.1 has made the assumption that we will do this, so that XPath expressions used in Conditional Type Assignment have access to attributes inherited from ancestor elements.
Comment 1 Michael Kay 2010-10-16 14:12:19 UTC
(See also bug #11062 on XSD).

On reflection, making inherited attributes available in the same way as ordinary attributes creates considerable problems for static type checking. It's not possible to examine an element declaration or its type and to work out statically from that that the element in question might inherit attributes from an ancestor; it's also possible for any inherited attributes to have a different type from like-named attributes declared locally on the element.

So if XDM does make inherited attributes available, perhaps they should not be presented (as they are in XSD Conditional Type Assignment XPath expressions) in the same way as local attributes. And if they are going to be treated differently, then perhaps the current way of accessing them - (ancestor::*/@x)[last()] - is good enough?
Comment 2 Norman Walsh 2010-11-16 16:36:54 UTC
This would complicate type checking. The attributes are available by looking up the ancestor tree in the natural way. We're not making a change for this.