This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
8.3.1 Matches Sem / rule 1 "AtomicTypeName1 derives from AtomicTypeName2" An AtomicTypeName isn't actually a TypeName (i.e., TypeName does not derive AtomicTypeName), so it doesn't conform to the judgment form declaration: "statEnv |- TypeName derives from TypeName" Sem / rule 1 / conclusion "AtomicValue of type AtomicTypeName" This is not valid syntax for a Value. Change "AtomicValue" to "AtomicValueContent". (leftover from last year, comment #238) Sem / rule 4 / conclusion "statEnv |- processing-instruction QName { String }" s/QName/NCName/ Sem / rule 8 / conclusion "attribute AttributeName of type TypeName { Value }" s/Value/SimpleValue/ (leftover from last year, comment #240)
Fixed as suggested. Made AtomicTypeNames derive from TypeName instead of directly deriving from QNames. - Jerome
Given the production AtomicTypeName ::= QName it's probably a bad idea to say/think that AtomicTypeName "directly derives from" QName. In terms of language theory, it's the other way round: AtomicTypeName directly derives QName. But if you mean that you replaced the above production with AtomicTypeName ::= TypeName then yeah, I think that will work.