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

[Chin Chee-Kai <cheekai@SoftML.Net>]

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