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

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

+1

On 01/03/07, David RR Webber (XML) <david@drrw.info> wrote:
> Steve,
>
> I'm not wanting to re-visit with Ken on the "it's not UBL if it does not
> have the namespaces and the XSD".
>
> What CAM can do for people is get them out of a practical hole with
> their XML and allow them to bridge to formal UBL depending on their
> operational needs and their partner systems.
>
> The key is - as you get more fielded UBL implementations out there -
> these production needs will drive future development of the standard
> and the practical tools used to support it.
>
> For example - if the Russian Government said - "we'd love to use UBL -
> but we need different tagnames for in country use" - then having the
> option to use CAM to morph between localization details and say an EU
> base-line - would obviously be enabling... and overall I'm guessing the
> bigger goal is UBL adoption and use, rather than say driving XSD
> adoption and use!?!
>
> 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: "Stephen Green" <stephengreenubl@gmail.com>
> Date: Thu, March 01, 2007 10:14 am
> To: ubl-dev@lists.oasis-open.org
>
> 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
>