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

["Stephen Green" <stephengreenubl@gmail.com>]

I get the feeling CAM validation which relies on an XML example
with supplementary XPath-based assertions and the CAM rules
would have no problem with this. That would be my preferance.
Then it doesn't matter which design of XSD is used, except
when this impacts the instance or where any business rules
are based on the XSD and have to be complied with. I'd be interested
in some algorithms that might take any implications of 'rules'
(not all of which might be deliberate) enforced by the XSD schema
and turn them into CAM equivalents. The design of the XSD schema
might have a bearing on how that might work and some schema
designs might make it easier - global or local.

Steve


On 01/03/07, Fraser Goffin <goffinf@googlemail.com> wrote:
> > 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
>
>