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

["David RR Webber \(XML\)" <david@drrw.info>]

Fraser,   

Just as an implementation note - CAM does allow you to look at structure
items to determine contextually what structure version is present - and
then apply structure validation accordingly.    

Also CAM gives you more latitude on the namespace labelling.  I have
seen production systems where older systems are not able to support all
aspects of namespaces - and require some latitude.  So having some
flexibility to convert between one non-normative XML format and a full
UBL format is always a positive.   

DW

"The way to be is to do" - Confucius (551-472 B.C.)
 

 -------- Original Message --------
Subject: Re: [ubl-dev] Hybrid approach to local vs. global
From: "Fraser Goffin" <goffinf@googlemail.com>
Date: Thu, March 01, 2007 9:35 am
To: ubl-dev@lists.oasis-open.org

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

Absolutely. All bets are off if the namespace binding are incorrect.
But this would be the same for any validating parser wouln't it.

That is, AFAIK most validating parsers use a schema cache of some
description and compare the namespace bindings in the XML instance to
those in the cache. Obviously if none match, then validation passes
(or perhaps more precisely, is not actually performed - either a false
positive or you deliberately want to ignore).

Fraser.

On 01/03/07, Bryan  Rasmussen <BRS@itst.dk> wrote:
>
> >(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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org