Re: [ubl-lcsc] Legal aspects of empty elements

["Chiusano Joseph" <chiusano_joseph@bah.com>]

The flip side of this is to use empty elements to mean "We are
maintaining that value in our system, but there is no value available
for this time period" vs. "We are not maintaining that value in our
system" (no tags sent at all for the value). I've seen this approach
used as well.

Of course, empty elements are easily handled in XML schema for strings
(simply specify xsd:minOccurs="0"), but not so easily for integers (and
integer-derived types). For the latter, one must use the "xsi:nil" facet
in an XML document:

<XYZAmount xsi:nil="true"/>

Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton

Alan.Stitzer@marsh.com wrote:
> 
> I can speak from the insurance industry point of view.
> 
> In the ACORD (insurance standards organization) specification, we state
> that empty tags are not allowed because of just what you state.  It would
> be impossible for one trading partner to understand what the other had
> meant if an empty tag had been sent....
> 
> ____________________
> Alan Stitzer
> AVP
> Marsh USA Inc.
> 1133 Avenue of the Americas
> New York, NY 10036-2774
> Phone: (561) 743-1938
> Fax: (561) 743-1993
> Internet: Alan.Stitzer@marsh.com
> ____________________
> 
> <<< Memo from cheekai@softml.net@Internet on 02 July, 2003, 06:25:29 AM
> Wednesday >>>
> 
> cheekai@softml.net@Internet on 2 Jul 2003, 06:25 Wednesday
> 
> To:    ubl-lcsc
> cc:      (bcc: Alan Stitzer)
> 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
> 
> To:    ubl-lcsc@lists.oasis-open.org@Internet
> cc:     (bcc: CN=Alan Stitzer/OU=NYC-NY/OU=US/OU=Marsh/O=MMC)
> From:  cheekai@softml.net@Internet
> 
> 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
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard