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

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

<Quote>
I read ahead on Joseph Chiusano's comments on this thread,
and seems like there's a recall for use of xsi:nil.
</Quote>

Clarification: My comment was strictly to provide information on W3C
Schema's handling of empty elements and the use of the xsi:nil in XML
instance documents (since I've encountered this in my work), and was not
intended to suggest any direction on this issue.

Chin Chee-Kai wrote:
> 
> On Wed, 2 Jul 2003, CRAWFORD, Mark wrote:
> 
> >>Our decision was based on both
> >>business and technical requirements and we agreed that
> >>empty elements should not be used in transaction-based
> >>exchanges.
> 
> This decision agrees with what I described:
> 
> >>> 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).
> 
> but does less in 2 aspects:
> 
> (1) It does not permit a statement of empty elements
>     rendered in the form of empty content.
> 
>      Note A: This is different from nil.
>      Note B: An empty string is a valid string and
>              cannot be ruled out a-priori that it is
>              not meaningful to all applications.
> 
> (2) When business semantics does require a statement of
>     empty value, the rule does not provision for it.
> 
> >>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.
> 
> I hope "discussed at length" is not given in the sense
> of a proof by intimidation in our discussions.  I've tried
> to refrain from reviewing the NDR rules just so things
> can settle down there, but since you brought it up and it's
> in LC list, here goes:
> 
> Rule 32 is confused between nil and empty content.
> 
> If you bring this in relation to my side-discussion about
> legal implications of empty elements (with empty content),
> rule 32 gives only one side of the picture and totally
> forgot about the reverse.
> 
> For the convenience of people following this discussion,
> 
> Rule 32 states:
> 
> "The nillable attribute must not be used in any UBL schema.
>  The element declaration of xsi:nil shall not appear in any
>  UBL conforming instance."
> 
> and "XML Schema Specification Part 1: Structures" states:
> 
> "XML Schema: Structures introduces a mechanism for signaling
> that an element should be accepted as valid when it has no
> content despite a content type which does not require or
> even necessarily allow empty content. An element may be
> valid without content if it has the attribute xsi:nil with
> the value true.  An element so labeled must be empty, but can
> carry attributes if permitted by the corresponding complex type."
> 
> The converse is not specified.  That is, an element having
> an empty content need not have xsi:nil and in the event that
> this is so, does not invalidate XML Schema Specification.
> And by this, where an application decides it is necessary to
> generate an empty content (by intent of user), it can do so
> without invoking the use of xsi:nil.
> 
> And so what you might have quoted for Rule 32 in response as
> "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."  is not applicable.
> 
> I think there is still a need for a statement to
> 
>    (1) State the business meaning it carries when
>        an empty element exists (without using xsi:nil),
> 
>    (2) State as a general guide that creation of empty
>        content elements must be the conscious intent
>        of the application (on behalf of user), to tie
>        back with the legal intent of the user.
> 
> (2) does not mean that when we state  this, it'll become
> a law (as in law in the society sense).  It will still need
> a legal framework to support the actual contratual legality.
> However, with my limited knowledge in guessing, I would
> suppose (2) could make it easier to embark on further
> discussions on the actual legal front to support transmission
> of UBL documents as expressions of legally binding
> contractual intents.
> 
> I read ahead on Joseph Chiusano's comments on this thread,
> and seems like there's a recall for use of xsi:nil.
> 
> Also, please Mark, I meant to start the discussion to seek
> some general feel from others and also to find some answers
> on various aspects of the topic on the way.  It seems almost
> true so far that whenever I touch on an NDR rule, it gets
> defended as if I have assaulted some gospel truths.  I see
> value and wisdom in the NDR list, but I also have some need
> to look ahead towards actual implementation, and that generates
> questions that I thought others might find as well, and could
> tap on UBL's list to discuss that.
> 
> If an outcome of the search is that NDR takes up to incorporate
> and change the checklist, that's well and good.  But if not,
> the rule can just as well stay, but actual implementers may
> or may not choose to follow.  So to me, it's just that simple.
> 
> Thanks.
> 
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6743-7875
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
> 
> >>
> >>> -----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
> >>
> >>
> 
> 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