On 12/20/11 11:36 AM, "Colm O hEigeartaigh" <[email protected]> wrote:
>What we could do is add some functionality that checks that each >(local) Reference URI in a Signature is in the document tree and is >unique. The reference itself is the result of resolution of the ID. If there's a duplicate, the results could be unique, but still wrong. The key point is that the app and the library have to resolve to the same reference element (and check transforms, etc.) One way is to expose the resolved element (see what was signed). Another is to enforce a totally app-controlled algorithm over resolution. I'm saying that DOM calls render the latter pretty difficult to pull off if the parser is allowed to be broken. > The retrieved element could be set on IdResolver. This way, >the tree is only walked once, instead of each time IdResolver is >called when resolving a reference, as is the case for 1.4.x. This >behaviour could be controlled by a property, possibly defaulting to >true. If you mean that the app tells the library what element a given ID should map to, I think that's what you're already doing, minus the fact that you're allowing for DOM lookup also. >Would this address your concerns? I think cutting off DOM support is a major step to take, since it's makes schema validation insufficient to establish IDness and will break existing apps. But if that's the conclusion (perhaps as an option or by default), then we need to clearly communicate that change, and I should implement something similar in C++. So far, I haven't taken any new steps because I'm waiting to see what the "right" answer is. -- Scott
