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

[Chin Chee-Kai <cheekai@softml.net>]

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