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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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

Subject: [ubl-ndrsc] Absence of Data

One thing that we'll have to deal with, particularly for those coming
from an EDI background, is that absence of data (or absent elements) are
not handled the same way.  For example:


<Name>     </Name>

All satisfy the condition that the "Name" element be present, even
though there may be no real data in it.

In X12 or EDIFACT:

N1*ST*Rawlins *91*1234567 - Element is present because data is present
N1*ST**91*1234567 - Element is not present because data is not present.

The PESC paper has a section which deals with this.  This may be a bit
long for our purposes, but I think it's something that needs to be

Extract from PESC paper:

2.3.9 Nulls, Zeroes, Spaces, and Absence of Data
The following rules SHALL apply in designing schemas and interpreting
instance documents:

1. Absence of data - If an element is defined as OPTIONAL (minOccurs
attribute value of zero) and the element does not occur in an instance
document, semantics SHALL NOT be interpreted from the element other than

that the originator of the instance document and did not include it.  No

default values are to be assumed.   Likewise, if an attribute is
declared as OPTIONAL (“use” attribute value of OPTIONAL) and the
attribute does not occur in an instance document, semantics SHALL NOT be

interpreted from the attribute other than that the originator and did
not include it; no default values are to be assumed.

NOTE:  All string items defined with a minOccurs of one SHALL have a
minimum length requirement of one character.

2. Zeroes - Zeroes, when appearing in a numeric element in an instance
document, SHALL be interpreted as a zero value.

3. Spaces - Spaces sent as values for elements or attributes (of type
string) in instance documents SHALL be interpreted as spaces.  It is
RECOMMENDED that leading and trailing spaces be removed, but when they
appear they SHALL have semantic significance.  Sending an element with
just spaces is not the same as sending a nulled element (see #4 below).

4. Nullability - In certain cases, it MAY be desirable to convey that an

element has no value (a null value) rather than indicating that it has a

value of spaces or that it is not present in a document.  In these
cases, the originator of the instance document SHOULD convey explicitly
that an element is null.  An example is an address update for a
previously transmitted address.  The previous address had two address
lines, whereas the current address has just one line.  The originator of

the document indicates that the second address line is removed by
indicating that the element is nulled as follows:
<addressLineTwo xsi:nill="true"></addressLineTwo>

To support this the addressLine element in the schema is defined as
nullable via:

<xsd:element name="addressLine" type="xsd:string" nillable="true"/>

When this type of nullable semantics are desired, the "nill" and
"nillable" attributes SHALL be used (as opposed to spaces for strings or

zeroes for numerics).   The "nillable" attribute SHALL NOT be used in
element declarations with a minOccurs of greater than zero.  When there
is a requirement that an element be OPTIONAL and not appear in an
instance document, the minOccurs attribute with a value of zero SHALL be

used in the element declaration.  By default, any element defined in
analysis as having a minimum occurrence of zero SHALL be represented in
the schemas as nullable.

Michael C. Rawlins, Rawlins EC Consulting

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

Powered by eList eXpress LLC