SV: [ubl-dev] Hybrid approach to local vs. global

["Bryan Rasmussen" <BRS@itst.dk>]

>(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