This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Following the static typing rules outlined in the Formal Semantics, we believe that static implementation will report XPTY0004. - in local:one_level, $p is statically typed as element() - $p/@partid is typed as attribute(partid, xs:anySimpleType)* - An implementation using the infoset mapping for fn:doc types $s/@partof as attribute(partof, xdt:untypedAtomic)* As a consequence, $s/@partof = $p/@partid should raise XPTY0004.
Marc: I asked for Jonathan's input on the matter. He wrote the use cases and is quite well versed on the use cases. Thanks, Carmelo
I agree with Marc. So how do we process this? At the very least, our test suites should allow static implementations to raise this error. We might want to fix this in the use cases document and think about when to republish, since we probably want the use cases to match the test suite and we probably don't want to penalize anyone for supporting static typing.
Mark/Jonathan: I can go ahead and change the test case entry in the catalog file to allow for a static error as well. Just need to think. How to set the scenario (standard or parse-error). Thanks, Carmelo
Agree. Test case entry in catalog was changed to allow for an alternate error to be raised. This may be a temporary solution if the use case gets changed. Thanks, Carmelo
This resolution is satisfactory, change state to closed.