This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
5.11 Module Import SCP / rule 1 / premise (2|3) "statEnv1 + varType(fs:local-variables(...))" "statEnv2 + localFunc(fs:local-functions(...))" This syntax is unspecified. SCP / rule 1 / premise 3 "statEnv2 + localFunc(...)" s/localFunc/funcType/ SCP / rule 1 / conclusion "import module (namespace NCName =)? ..." If NCName appears, it should be bound to the target namespace in statEnv.namespace. Notation 2 "The rules below depend on the following auxilliary judgments." Presumably, this should be followed by declarations of the "=>import_variables" and "=>import_functions" judgment forms. Such a Notation section should precede the DCP section though. "This judgment adds each ..." (twice) s/judgment/rule/ DCP / rule 2 dynEnv2 ; URI |- (expanded-QName2(Type2,1, ..., Type2,n)), ยทยทยท," (expanded-QNamek(Typek,1, ..., Typek,n)) => ... This requires that all functions imported from a module have the same number of arguments (n), which is not what you want. You could fix this with subscripts-on-subscripts, but that would make the rule harder to read and understand. The better route, which actually makes the rule *easier* to read and understand, is to introduce a Formal symbol for (this kind of) function signature. "to the input dynamic context." "input"? Maybe s/input/importing/ DCP / rule 3 / premise (2|3) "fs:local-foo(statEnv2, URILiteral1)" Delete the subscript 1. "URILiteral ; dynEnvi |-" Change to "dynEnvi ; URILiteral |-" to match previous rules. dynEnv2, statEnv2 It's not clear why dynEnv2 isn't used, or where statEnv2 comes from.
*** Bug 1900 has been marked as a duplicate of this bug. ***
Fixed as suggested when possible, since some of those comments were taken over by events. - Jerome
The 2006-06 CR does not have fixes for some of the items, specifically: Notation 3 "The rules below depend on the following auxilliary judgments." But no auxiliary judgments are set out. Notation 3 / rule (2|4) This requires that all functions imported from a module have the same number of arguments (n), which is not what you want. (This comment dates back to April 2004.) Notation 4 / rule 2 It's not clear why dynEnv2 isn't used, or where statEnv2 comes from. (And by the way, premises 1 and 2 are identical.)
The second item of Comment #3 has been resolved by the fix for FS erratum E006.