OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-lcsc] Legal aspects of empty elements


We have already discussed this at length in NDR.  There is no need for the rule you suiggest as we have already made this decision vis a vis use of the nill attribute - Rule 32. Our decision was based on both business and technical requirements and we agreed that empty elements should not be used in transaction-based exchanges. 

Mark


> -----Original Message-----
> From: Chin Chee-Kai [mailto:cheekai@softml.net]
> Sent: Wednesday, July 02, 2003 6:04 AM
> To: UBL LCSC
> Subject: [ubl-lcsc] Legal aspects of empty elements
> 
> 
> This is related, but separate discussion with the empty
> elements found in the sample instances 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]