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 5494 - inherit schematron constraints from the substitution group head
Summary: inherit schematron constraints from the substitution group head
Status: RESOLVED FIXED
Alias: None
Product: SML
Classification: Unclassified
Component: Core (show other bugs)
Version: LC
Hardware: PC All
: P2 normal
Target Milestone: LC
Assignee: Kumar Pandit
QA Contact: SML Working Group discussion list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2008-02-20 01:19 UTC by Kumar Pandit
Modified: 2008-02-22 02:12 UTC (History)
0 users

See Also:


Attachments

Description Kumar Pandit 2008-02-20 01:19:05 UTC
Currently the spec defines in section 6.3.1 how a complex type inherits schematron constraints from its base type definition. However, the spec does not define how an element declaration inherits schematron constraints from a substitution group head. This makes it inconsistent with the behavior of other SML constraints. All other SML constraints are inherited through substitution.

Proposal:
Update bullet# 2 in 6.3.1 as follows:

---
The value of {rules} property of a schema component is computed as follows:
1. The value of {rules} for xs:anyType is the empty set. 
2. If the schema component is a global element declaration, then the value of its {rules} is the union of its local-rules and the appropriate case from the following: 
   a. If the element declaration has a {substitution group affiliation}, then the value of {rules} of the {substitution group affiliation}.
   b. Otherwise (the element declaration has no {substitution group affiliation}), the empty set.
3. If the schema component is a complex type definition, then the value of its {rules} is the union of its local-rules and the appropriate case from the following:
   a. If {base type definition} is a complex type definition, then {rules} of the {base type definition}. This is true for derivation by extension as well as for derivation by restriction. 
   b. Otherwise ({base type definition} is a simple type definition), the empty set. 
---

Note: bullets 1 & 3 are unchanged. They are shown above only to provide context.
Comment 1 Pratul Dublish 2008-02-20 01:21:44 UTC
Agree with Kumar's proposal
Comment 2 Virginia Smith 2008-02-21 19:46:25 UTC
Resolution on 2/21 call is to fix per proposal; no needsReview.
Comment 3 Kumar Pandit 2008-02-22 02:12:13 UTC
fixed as proposed.