[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Hybrid approach to local vs. global
Hi All, I'm not sure the problem here is global vs local. I think it's whether there should be an approach where two sets of schemas are produced by ATG2 which validate (identically?) the same instances. Several of us have found that this is not only doable but I think I also showed that a stylesheet transformation from all-global to the ATG2 local design (at it stood then) was possible and I submitted a sample doing some of that (but without certain features I think, such as alphabetic sorting). I worked out that the UBL schema design included all the ATG2 schema design schemas' information but added more besides so the transformation would only work the one way. This meant that one way to do this was to just produce the UBL NDR schemas with a stylesheet to create the local ATG2 design schemas. Of course, things may have changed since then so I'm not sure it could be done as the designs stand now. If things haven't changed much though it might be feasible still. Now I'm feeling more inclined to suggest that this is a flawed position since it seems more in line with the spirit of CCTS to concentrate on the model (BIEs and CCs) and not require a certain schema design when it comes to a purely CCTS implementation (I'd see UBL as CCTS made more pragmatic for the time as a kind of safety net before trying the full adventurous but relatively unproven CCTS ideal). So ATG2 could still issue the NDRs and even make them conform to something which would work as a hybrid approach as above but I'd see a better option than issuing the only normative sets of schemas in this way as just leaving it that the model is normative and the NDR and schemas are not normative as essential to implementing ATG2 but normative as further implementations among several possible implementations. This I'd call separately normative. A bit like the UBL codelist methodology (? - correct me if I'm wrong). All the best Stephen Green >>> Chin Chee-Kai <cheekai@SoftML.Net> 07/03/07 16:31:02 >>> >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. While I agree with you that "problem" of this sort, being a part of the XML schema itself, could be circumvented, ignored, or patched somehow so as to cover it up. But here, I'd like to refocus on the subject title that started off this thread, which is to determine the best approach, if such exists, in utilizing XML schema to describe UBL's data models. The discussion here is not so much to keep pointing out that XML schema is problematic. Rather, it is how UBL utilizes the various facets of XML schema that would lead to further amplification of problems if we all believe, as we somehow do, that UBL would proliferate in years to come. >>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 don't really think the "global" declaration is an attribute of specific implementation of schema/xml processors; it is part of the XML schema spec. Its defined semantics that merge the meanings of both the globality of top-level tagnames with tagnames that are available as candidates for instance validation is causing the problem here. >>I'm not exactly sure what a cbc:ID would produce, probably also valid. I think the document I gave earlier had several examples which (off my mind) included this, or some similarly trivial but weird ID example. >>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. Ah hah, I haven't brought in namespace discussion yet. I thought Jon merely required views on local vs global. Namespace discussions could take up a whole thread by itself. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6820-2979 Email: cheekai@SoftML.Net http://SoftML.Net/ --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org ______________________________________________________________________ Please note the new simpler name for our website: http://www.bristol.gov.uk Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details. Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect ______________________________________________________________________ Please note the new simpler name for our website: http://www.bristol.gov.uk Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details. Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]