[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [ubl-dev] Hybrid approach to local vs. global
>(2) the problem with global elements during validation - > introduction of additional unexpected "valid" data elements > because of imports and inclusion of other UBL sub-modules. > This, therefore, poses a potential security issue there as well. hmm. not sure if I agree with that (or at least if I agree 100%). The problem alluded to in your document is one of the more annoying parts of the use of XML schemas, because not very many people are even aware it exists. Some day some enterprising cracker is going to figure out a way to take advantage of this situation. The problem is however not present everywhere that global elements are used, it is present where global elements are used dependent on the processor used and dependent on how validation is set (strict, lax, or skip), for example IIRC validating a cac:PaymentMeans with the Invoice Schema on XSV should produce a report of valid using lax validation. I'm not exactly sure what a cbc:ID would produce, probably also valid. also a <doc:whatever>with a cac:PaymentMeans inside of it would also produce valid (at one time, haven't used XSV in a long time and new versions have been released so this may be a case of something in an earlier version having been changed [not fixed but just changed, from my reading of the Schema spec]) But doing any of these things with MSXML's Schema Cache or .Net should produce a report of not valid using strict validation. XMLSpy seems to vary on how it handles the matter. The problem can also be alleviated easily enough by implementors checking the namespace and document element of incoming messages, which is basically what I always do before considering anything like validation, transformation, anything. Cheers, Bryan Rasmussen
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]