[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-lcsc] Legal aspects of empty elements
Hi I've been accustomed to talking about mandatory / optional entites as part of the tightness / looseness of the schema. It is, in my view, one of the most important factors to consider when deciding whether to use a schema or not. Legal considerations are one aspect along with business issues such as whether you actually need to send/receive recipt advices or order responses. A stated goal of UBL is to seek to achieve 80:20 applicabilty. So to achieve this goal, I think, we certainly nee to get it right about what is and what isn't mandatory - and with business and legal factors in mind, that obviously means not-blank too. I hope this 'will all come out in the wash' as we approach 1.0 but I'm a little worried that it might not get exact enough attention. I find it a useful exercise to look at the minimal instance and see if it satisfies my business/legal requirements. From the examples too, I'd have a few concerns. One is that in some ways it is too 'loose' regarding ID's (in that these can be blank). This is especially a concern for Seller and Buyer party. Another concern is that there are sometimes more than one place where business data can be placed in an instance. again this is exemplified in the party name which could be treated as an ID entity or, if this seems obscure, as an AlternativeParty/Name. It could actually be treated in afew other ways too. This might be OK with data not crucial to a party's system but for crucial data such as buyer and seller identifiers it would probably necessitate greater costly human intervention in the process. Steve >>> Chin Chee-Kai <cheekai@softml.net> 07/02/03 11:24 AM >>> This is related, but separate discussion with the empty elements found in the sample insances done by Stephen. I don't profess to know much about legality, but the question I have is based on normal working experience. And I'm seeking perhaps some answers or initial thoughts on this towards the direction of actual implementation. In normal contracts, of which P.O. is one type, there is a slight difference between not stating something, as opposed to stating an empty return. The difference is mostly acceptable if everything goes well, but becomes basis for sometimes great grounds for dispute when things go astray. Now in the electronic equivalent in XML, the technology permits the equivalent of stating empty value (instantiate element which contains empty string) versus not stating at all (no instantiation). So if we have a policy or rule of some sort that says we do not instantiate unless instance applications consciously wish to indicate an empty value, then it seems to match closer to normal business practice. (A more compact instance representation comes as a bonus, though I think the implications derived seems to value more). What does the list think about this? Or does it fall outside LC's scope, or even UBL's scope? Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6743-7875 Email: cheekai@SoftML.Net http://SoftML.Net/ You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]