[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Hybrid approach to local vs. global
+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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]